UML2notes

“——————————————————————————————————————————————————

Support translation: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”The UML is the standard language for specifying, visualizing, constructing, and documenting all the artifacts of a software system.””
Activity Diagrams
The logical place to start walking through some of the UML diagrams is by looking at activity diagrams.
Figure 2: Activity diagram
Activity diagrams show the flow of control. As illustrated in Figure 2, you can see activities represented as rounded rectangles. Activities are typically action states — states that transition automatically to the next state after the action is complete. The filled in circle represents the start of the activity diagram — where the flow of control starts. Transitions shown as arrows show how you move from activity to activity. Synchronization bars show how activities happen in parallel. I can guard a transition that says “”I want you to go to this activity only if this condition is true,”” and I can show you where it stops. Now if you’re a certain age, you’ll probably look at this activity diagram and think, “”hmm … that looks like a flow chart.”” And that’s exactly what it is, except I’m not doing it down at the programming level. Typically, I use an activity diagram fairly early on in my analysis and design process to show business workflow. I’ll also use them to show where each of my use cases might be in an activity to illustrate what use case has to happen. I also use activity diagrams to show how things flow between my use cases.
But one of the great things about the UML is its versatility. So while I use activity diagrams at the beginning of the lifecycle, others can use them in a different phase entirely. I’ve seen people use activity diagrams down at the design level where they had a very complicated set of algorithms for a particular class. And many people use them to show the flow between the methods of a class.
the system. Actors are represented as stick figures.
Figure 4: Actors
The example that I worked up for this introduction to UML is a little model of a course registration system. So in this instance, the first thing I would do when starting my analysis process is to ask, “”who is going to interact with this system?””
For the course registration model, I have a registrar, a professor, and a student. I also have an external billing system. This billing system also qualifies as an actor. (See, an actor doesn’t have to be a person — it’s anything that interacts with the system but is outside of the system.)
A use case is a sequence of related transactions performed by an actor in the system in a dialog. Or, to put it in English, a use case is a chunk of functionality. And here’s the key: it is not a software module — it is something that provides value to the actor.
Use cases are shown as ovals, and the easiest way to find them is to look at each of your actors and ask yourself why do they want to use the system. In my case, my registrar is going to maintain the curriculum, my professor is going to request a roster, my student maintains the schedule, and my billing system receives the billing information. So I create my use cases by looking at it from the customer point of view and asking, “”so, mister system actor, why do you want to use the system? What value does this system provide to you?””
The next step, once you’ve identified how your actors will be interacting with the system, is do document your use cases. Each use case needs to be documented with the flow of events, and this is done from the actor’s point of view. It should detail what the system must provide to the actor when the use case is executed. Typically it will show things like how the use case starts and finishes. What things does that use case have to do? You’ll have the normal flow of events (what I call the “”happy days”” scenario), where everything works. Then you’ll get the abnormal flow of events, the “”rainy day”” scenario. What happens when the system doesn’t work? I’ve found by documenting my flow of events that I always start with the happy days scenario.
Take as an example, walking up to an automated teller machine. You walk up to the ATM and insert your card. It asks for your PIN number. You enter it, and you are asked what you would like to do. You say “”I want some money.”” It asks where the money should be taken from. You tell it to take it from your checking account. It asks how much. You say $100.00. Then magic happens … it gives you $100.00. Then it asks if you want another transaction. You say no. It gives you your card back, gives you a receipt, and the transaction is over. That’s the happy day scenario.
Second scenario. You go up to the ATM, insert your card, and enter your PIN. The ATM tells you it’s the wrong PIN. You enter your number again. Again you are told that the PIN is incorrect. You In my course registration example, for instance, you can see that there are a lot of “”if X then Y”” workflows. That’s where you want your customer to help you out. Getting agreement early means your customer understands these scenarios and says “”yes, this is what we want.”” Use cases are a great way to ensure that what you’re building is really what the customer wants, because they show the actors, the use cases, and the relationships between them.
Figure 5: Use case diagram
So we have a great diagram that graphically shows me what? The answer is simple — it is a great diagram that shows a good overview of the system. It shows what is outside the system (actors) and the functionality that the system must provide (use cases). If there is a legacy system you need to take into consideration, here’s where you deal with it. Forcing me to work with these types of interfaces very early in the project means that I won’t be faced with the prospect of waiting until coding starts to figure out how I’m going to talk to that black box that I can’t change.
One more thing you should know about use cases is the use case realization. This is the “”how”” of the use case. It’s usually a bucket that contains three different types of diagrams: sequence diagrams, collaboration diagrams, and a class diagram that we call a view of participating classes. Use case realizations are basically a way of grouping together a number of artifacts relating to the design of a use case.
Sequence Diagrams
Sequence diagrams show object interactions arranged in a time sequence. I can use the flow of events to determine what objects and interactions I will need to accomplish the functionality specified by the flow of events.
Figure 6: Sequence diagram
Figure 6 shows how a student successfully gets added to a course. The student (let’s call him Joe) fills in some information and submits the form. The form then talks to the manager and says “”add Joe to Math 101.”” The manager tells Math 101 that it has to add a student. Math 101 says to Section 1 “”are you open?”” In this case, Section 1 replies that they are open, so Math 101 tells section 1 to add this student. Again, sequence diagrams are great tools in the beginning because they show you and your customer step-by-step what has to happen.
From an analysis point of view, I’ve found over the years that sequence diagrams are very powerful in helping me drive requirements; especially requirements that are hard to find. User interface requirements, for instance, are notorious because you always seem to get requirements that are just not testable. A common UI requirement like this is “”this system shall be user-friendly.”” How many of you have met a friendly computer? One of the benefits of these types of diagrams is that every line coming from an actor that represents a person, tells you that something in your UI has to provide a capability needed by that person. In other words, you can use sequence diagrams to drive out testable user interface requirements.
Sequence diagrams are, therefore, good for showing what’s going on, for driving out requirements, and for working with customers. That usually leads to the question, though, of how many do you need to create? My answer is, “”until you do enough.”” You’re going to find out when you do sequence diagrams that you reach a point where you’re not finding any new objects, not finding any new messages, and that you’re typing the same thing over and over. In the example of Joe joining Math 101, we learn that the process would be the same if Joe wanted to join History 101. So, rule of thumb, do a sequence diagram for every basic flow of every use case. Do a sequence diagram for high-level, risky scenarios, and that should be enough. That’s how many sequence diagrams I do.
to remember here, is that a collaboration diagram is just a different view of a scenario and you can go back and forth between sequence diagrams and collaboration diagrams to get the view that best illustrates your point.
Occasionally, you might hear the phrase “”interaction diagrams.”” Sometimes people will collectively refer to a collaboration diagram and a sequence diagram as an interaction diagram.
Class Diagrams
A class is a collection of objects with common structure, common behavior, common relationships, and common semantics. You find them by examining the objects in sequence and collaboration diagrams, and they are represented in the UML as a rectangle with three compartments.
Figure 8: Classes
The first compartment shows the class name, the second shows its structure (attributes), and the third shows its behavior (operations). These compartments can be suppressed, however, so that you can see just the name, just the name and the attributes, or all three. One thing you should also know is that it’s important, when naming classes, to use the vocabulary of the domain and pick a standard. For this instance, my classes are all singular nouns that begin with a capital letter. You may choose to do it differently, and that doesn’t matter. What does matter is that before your project you pick a standard and stick with it so that everything is consistent across the project.
Class Diagrams show you the static nature of your system. These diagrams show the existence of classes and their relationships in the logical view of a system. You will have many class diagrams in a model.
The UML modeling elements found in class diagrams include:
Classes and their structure and behavior.
Association, aggregation, dependency, and inheritance relationships.
Multiplicity and navigation indicators
Role names.
Take a look at Figure 9. This diagram shows operations (behavior): what an object in that class can do. I find my operations by looking at my interactions diagrams.
Figure 9: Operations
Here I’m saying that I need to be able to ask the registration manager to add a student to Math
101. That’s going to translate into an operation called “”addCourse.””
The structure of a class is represented by its attributes. So how do I find my attributes? By talking to domain experts. By looking at my requirements. In my example, I learn that each course offering has a number, a location, and a time. This translates out to three attributes.
classes. (Represented in the UML as a line connecting the related classes with a diamond next to the class representing the whole.)
• Dependency — a weaker form showing the relationship between a client and a supplier where the client does not have semantic knowledge of the supplier. A dependency says “”I need your services, but I don’t know that you exist.”” (Represented in the UML as a dashed line pointing from the client to the supplier.)
To find relationships, once again, I go back to my sequence diagram. If two objects need to “”talk””, there must be a means to do so (i.e., a relationship between their classes).
I typically start out and make everything an association. As I’m doing more analysis, I might find I have an aggregation because I’m going to have to take care of a parent-child relationship. When I get into the design phase, I find out that I might not need an association because somebody else is going to pass that object into one of my methods — so I make it a dependency.
Figure 11: Relationships
In Figure 11 you see these relationships. As association says the Professor can talk to the Course Offering, and the Course Offering can talk to the Professor. Messages can be initiated and data can flow from any direction. Aggregation is shown by having the diamond toward the whole — in this case a Course is made up of Course Offerings. The reason for this aggregation would be to tell my developers that if they get rid of this Course, they’ll probably have to do something special with the Course Offerings. Dependencies are shown as a dashed line. It’s saying that the registration manager depends upon the Schedule Algorithm to do something. The Schedule Algorithm is either a parameter to one of the methods or is declared locally by one of the Methods of the Registration Manager.
Multiplicity and Navigation
Multiplicity defines how many objects participate in a relationship. It is the number of instances of one class related to one instance of the other class. For each association and aggregation, there are two multiplicity decisions to make: one for each end of the relationship. Multiplicity is represented as a number and a * is used to represent a multiplicity of many.
Figure 12: Multiplicity and navigation
One Professor Object is related to zero-to-four Course Offering Objects. One Course Offering Object is related to exactly one Professor Object. I use this to look at and ensure that this handles my requirements. Can I be a Course Offering and be team-taught by a bunch of professors? No, because this says I can only have one professor. Can I be a professor and be on sabbatical? Yes, because this says I have a zero as possible course load. I use multiplicity quite often to help me start capturing and implementing my business rules. If you have, for example, a business rule that says you must have at least 3 students and no more than 10 for a course to be offered in a semester, these multiplicity numbers tell me I’ve incorporated that business rule into this plan.
Navigation is shown by an arrow, and although associations and aggregations are bi-directional by default, it is often desirable to restrict navigation to one direction. When navigation is restricted, an arrowhead is added to indicate the navigational direction. One of the things I do during the analysis and design phases is look at what I want to be uni-directional. By putting the arrow into this diagram, I say that the Registration Manager can send a message to the Course, because it knows the Course exists. But the Course has no idea that the Registration Manager exists, so the Course cannot initiate a message. Now data can flow between them; for instance the Registration Manager can ask the Course if it’s open and the Course can say that it is. But only the Registration Manager can start that conversation.
Obviously the goal here is to get as many arrows as you can by the time you’ve finished designing, because it’s a much easier system to maintain Inheritance is shown with a triangle. This shows that the Professor is a Registration User, as is the Student. Now, a word of warning. Inheritance is useful, however, the goal is not to use as much inheritance as your system will allow. I’ve seen some really brutal systems where they had inheritance 17-levels deep. If they changed one thing, it became a disaster. So the rule of thumb is to use inheritance only when you truly do have an inheritance situation.
State Transition Diagrams
A state transition diagram shows the life history of a given class. It shows the events that cause a transition from one state to another, and the actions that result from a state change.
Figure 14: State transition diagram
I use state transition diagrams for object classes that typically have a lot of dynamic behavior. The button is on … the button is off; I’m not going to do a state chart for it. But object classes that have a lot of dynamic behavior, I’m probably going to have to look into the states of the objects.
I start by showing a state, which is a rounded triangle. I can have start states, and I can have stop states, which are shown as bulls eyes. I can also have transitions between states, or guard transitions (things that happen when only when a condition is true), or things that happen when I’m inside the state. I look at this diagram and see the state transition diagram for a course offering. It starts in the initialization state, and I stay in that state until I get an “”add student”” message. When I get that message, I set my count of student to zero and I transition to the Open state. You’ll see in Figure 14 that I have an entry, and the reason why it’s there is that I have two ways of getting into that state. It says that no matter how you come into the state, I want you to register the student. When I exit that state, the count changes to keep track of the number of students in the course. I can keep adding students until I get to 10, and then I go to the Close state. Once the course is finalized, I transition to the stop state. No matter where I am then, if I get the Cancel Event transition, I notify my students and then transition to the stop state.
For object classes that have a lot of dynamic behavior, it’s well worth it to do a state diagram to get a handle on everything that has to happen. Ask yourself what happens when I get a message? What do I do when I get the message? What messages to I have to send? A lot of those messages become operations of the object class, as in this example where add a student is an operation. A lot of these actions, like setting the count, incrementing the count, checking the count, these all become private operations of that particular object class and a state diagram is where I see that.
How do you know if you have a dynamic object class? Once again, go back to the sequence diagrams. If you have an object class that’s on a lot of sequence diagrams and it’s getting and sending a lot of messages, that’s a good indication it’s a fairly dynamic object class and it should probably have a state chart for it. Also for aggregations, where you have the whole of its parts, I do a state chart for every aggregate whole. I do this mostly because that aggregate whole is often responsible for managing the messaging, which makes it dynamic.
Component diagrams
Of course no system can be built without taking into account the physical world. That’s where component diagrams come in. They are used to illustrate the organizations and dependencies among software components, including source code components, run time components, or an executable component. Components are shows as a large rectangle with two smaller rectangles on the side, as seen in Figure 15.
Figure 15: Components
Those round things represent interfaces (often called lollipop notation). In this case, they show that the Register.exe is dependent upon interfaces to both the Course.dll and the People.dll. That means if these interfaces change, it will impact the Register.exe. I know that there’s this rule when you’re building interfaces that says “”thou shall not change the interface.”” But does anybody actually work where that rule is enforced? This diagram tells us what interfaces are used by what executables are running on my processors.
Figure 16: Deployment diagram
Extending UML
The last thing I want to stress about the UML is that it can be extended. When they built the UML, they very wisely realized that there was no way they could create a notation that could please all of the people all of the time. So they gave us the concept of a stereotype. A stereotype says I can take a basic modeling element and give it more meaning. Stereotypes may be used to classify and extend associations, inheritance relationships, classes, and components.
Figure 17: Web stereotype example
Figure 17 shows the diagram of our Web stereotypes. A Web page typically has stuff that runs on the server and stuff that runs on the client. If you’re building Web-based applications, what’s running on the client and the server is of vital importance. So we have a whole set of stereotypes that show that. The little wheels represent things that run on the server. So just by looking at this one diagram I can see what runs on the server, what runs on the client, and what business objects they have to deal with.

“——————————————————————————————————————————————————

Appoġġ traduzzjoni: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”L-UML huwa l-lingwa standard għall jispeċifika, viżwalizzazzjoni, kostruzzjoni, u jiddokumenta l-artifacts ta ‘sistema ta’ softwer.””
Attività Dijagrammi
Il-post loġiku biex tibda mixi permezz xi wħud mill-dijagrammi UML huwa billi tħares lejn dijagrammi attività.
Figura 2: Dijagramma Attività
dijagrammi Attività juru l-fluss ta ‘kontroll. Kif muri fil-Figura 2, tista ‘tara l-attivitajiet rrappreżentati bħala rettangoli mqarrba. Attivitajiet huma tipikament imsemmija azzjoni â € “”jgħid din it-tranżizzjoni awtomatikament lill-Istat li jkun imiss wara l-azzjoni hija kompluta. Il mimlija fil-ċirku jirrappreżenta l-bidu tal-dijagramma attività â € “”fejn il-fluss ta ‘jibda’ kontroll. Tranżizzjonijiet murija bħala vleġeġ juru kif inti timxi minn attività għall-attività. vireg sinkronizzazzjoni juru kif l-attivitajiet jiġri b’mod parallel. I tista ‘gwardja transizzjoni li tgħid “”Irrid li inti tmur għal din l-attività biss jekk din il-kundizzjoni hija vera,”” u I jistgħu nuruk fejn huwa obbligat jieqfu. Issa jekk int ċerta età, inti probabilment tħares lejn din dijagramma attività u think, “”Hmm â € |. Li qisu flow chart”” U dan huwa eżattament dak li hi, ħlief jien ma nagħmilx hekk stabbiliti fuq il-livell ta ‘programmar. Tipikament, I-użu dijagramma attività pjuttost kmieni fl-analiżi u d-disinn tiegħi proċess li juru workflow negozju. I ser ukoll jużawhom biex juru fejn kull waħda każijiet ta ‘użu tiegħi jista’ jkun f’attività biex juru dak il-każ l-użu għandu jiġri. I wkoll jużaw dijagrammi attività biex juru kif fluss affarijiet bejn każijiet ta ‘użu tiegħi.
Iżda waħda mill-affarijiet kbar dwar il-UML huwa versatilità tagħha. So I filwaqt li jużaw dijagrammi attività fil-bidu tal-ħajja, oħrajn jistgħu jużawhom fil-fażi differenti għal kollox. Stajt tidher nies jużaw attività dijagrammi stabbiliti fuq il-livell tad-disinn fejn kellhom sett ikkumplikat ħafna ta ‘algoritmi għal klassi partikolari. U ħafna nies jużawhom biex juru l-fluss bejn il-metodi ta ‘klassi.
-sistema. Atturi huma rappreżentati kif stick figuri.
Figura 4: Atturi
L-eżempju li ħdimt għal din l-introduzzjoni għal-UML huwa mudell ftit ta ‘sistema ta’ reġistrazzjoni kors. Allura f’dan il-każ, l-ewwel ħaġa li nixtieq nagħmel meta jibdew proċess ta ‘analiżi tiegħi huwa li jistaqsi, “”li tkun se jinteraġixxu ma’ din is-sistema?””
Għall-mudell reġistrazzjoni course, I jkollhom reġistratur, professur, u student. I wkoll ikollhom sistema ta ‘kontijiet esterna. Din is-sistema ta ‘kontijiet tikkwalifika wkoll bħala attur. (Ara, attur ma kellhiex tkun persuna € “”huwa kwalunkwe ħaġa li jinteraġixxi mas-sistema, iżda hija barra tas-sistema.)
Każ użu hija sekwenza ta ‘tranżazzjonijiet relatati li jsiru minn attur fis-sistema dialog. Jew, fi kliem bl-Ingliż, f’każ użu huwa blokki ta ‘funzjonalità. U hawnhekk l-muftieħ: mhuwiex softwer modulu â € “”huwa xi ħaġa li tipprovdi valur lill-attur.
każijiet ta ‘użu huma murija bħala ovali, u l-eħfef mod biex isibu lilhom hi li tħares lejn kull wieħed atturi tiegħek u staqsi lilek innifsek għaliex huma jixtiequ li jużaw is-sistema. Fil-każ tiegħi, reġistratur tiegħi se jinżamm il-kurrikulu, professur tiegħi se titlob roster, student tiegħi iżomm l-iskeda, u sistema ta ‘kontijiet tiegħi tirċievi l-informazzjoni ta’ kontijiet. So I joħolqu każijiet ta ‘użu tiegħi billi tħares lejn din mill-punt klijent di vista u tistaqsi, “”hekk, attur sistema nida, għaliex tridu jużaw is-sistema? X’inhu valur ma din is-sistema tipprovdi għalik?””
Il-pass li jmiss, ladarba inti ħadthom identifikati kif l-atturi tiegħek ser jiġu f’kuntat mal-sistema, hija do dokument każijiet ta ‘użu tiegħek. Kull każ użu jeħtieġ li jkun dokumentat mal-fluss ta ‘avvenimenti, u dan isir mill-punt l-attur ta’ opinjoni. Għandha dettall liema s-sistema għandha tipprovdi lill-attur meta l-każ użu tkun imwettqa. Tipikament ser juru affarijiet simili kif il-każ l-użu jibda u finituri. Liema affarijiet ma F’dak il-każ l-użu għandek tagħmel? Int ser ikollok l-fluss normali ta ‘avvenimenti (dak I-sejħa tal- “”jiem kuntenti”” xenarju), fejn jaħdem kollox. Imbagħad int ser tingħata l-fluss anormali ta ‘avvenimenti, il- “”ġurnata ta’ xita”” xenarju. X’jiġri meta s-sistema ma taħdimx? Stajt misjuba mill jiddokumenta fluss tiegħi ta ‘avvenimenti li jien dejjem tibda bil-ġranet kuntenti xenarju.
Ħu bħala eżempju, mixi sa teller machine awtomatizzata. Inti timxi sa l-ATM u daħħal il-karta tiegħek. Hija tistaqsi għall PIN numru tiegħek. Inti tidħol fih, u inti mitlub dak li inti tixtieq li tagħmel. You say “”Irrid xi flus.”” Hija tistaqsi fejn il-flus għandhom jittieħdu minn. Inti tgħid li teħodha mill-kont tiegħek verifika. Hija tistaqsi kemm. You say $ 100.00. Imbagħad magic jiġri € | tagħtik $ 100.00. Imbagħad, hija tistaqsi jekk inti tixtieq transazzjoni ieħor. Inti tgħid le. Dan jagħtik il-karta tiegħek lura, jagħtik irċevuta, u l-operazzjoni huwa fuq. Dik hija l-xenarju jum kuntenti.
It-tieni xenarju. Inti tmur sa l-ATM, daħħal il-karta tiegħek, u jidħol PIN tiegħek. Il-ATM jgħidlek huwa l-PIN ħażin. Inti tidħol in-numru tiegħek mill-ġdid. Għal darb’oħra inti qal li l-PIN hija żbaljata. You Fil-kors tiegħi eżempju reġistrazzjoni, per eżempju, tista ‘tara li hemm ħafna ta’ “”jekk X imbagħad Y”” flussi tax-xogħol. Li meta inti tixtieq klijent tiegħek biex jgħinuk. ftehim Getting bikri tfisser klijent tiegħek jifhem dawn ix-xenarji u jgħid “”iva, dan huwa dak li rridu.”” każijiet ta ‘użu huma mod tajjeb ħafna biex jiżguraw li dak li int bini huwa verament dak li jrid il-klijent, għaliex juru l-atturi, il-każijiet ta’ użu, u r-relazzjonijiet bejniethom.
Figura 5: Uża każ dijagramma
Allura aħna għandna dijagramma kbir li grafikament juri me dak? It-tweġiba hija sempliċi € “”huwa dijagramma kbir li juri ħarsa ġenerali tajba tas-sistema. Dan juri x’inhi l barra mis-sistema (l-atturi) u l-funzjonalità li s-sistema għandha tipprovdi (każijiet ta ‘użu). Jekk ikun hemm sistema wirt għandek bżonn tieħu in kunsiderazzjoni, hawn fejn inti jittrattaw dan. Furzar biex naħdem ma ‘dawn it-tipi ta’ interfaces kmieni ħafna fil-proġett ifisser li jien mhux se jiġu ffaċċjati bil-prospett ta ‘stennija sakemm kodifika jibda biex insemmu kif jien ser jitkellmu għal dik kaxxa s-sewda li ma nistax bidla .
Ħaġ’oħra inti għandek tkun taf dwar każijiet ta ‘użu huwa l-realizzazzjoni każ użu. Din hija l- “”kif”” ta ‘l-użu każ. Huwa ġeneralment barmil li fih tliet tipi differenti ta ‘disinni: dijagrammi sekwenza, dijagrammi kollaborazzjoni, u dijagramma klassi li nsejħu ħsieb ta’ klassijiet parteċipanti. każ realizzazzjonijiet użu huma bażikament mezz ta raggruppament flimkien numru ta ‘artifacts relatati mad-disinn ta’ każ użu.
sekwenza Dijagrammi
dijagrammi Sekwenza juru interazzjonijiet oġġett rranġati f’sekwenza żmien. I jistgħu jużaw il-fluss ta ‘avvenimenti biex jiddeterminaw liema oġġetti u interazzjonijiet jien ser bżonn sabiex iwettaq l-funzjonalità speċifikata mill-fluss ta’ avvenimenti.
Figura 6: dijagramma sekwenza
Figura 6 turi kif student b’suċċess gets miżjuda għal kors. L-istudent (ejja jsejjaħħlu Joe) timla xi informazzjoni u tissottometti l-formola. Il-formola mbagħad taħdidiet għall-maniġer u jgħid “”żid Joe għal Matematika 101.”” Il-maniġer jgħidlekx Matematika 101 li hija għandha biex iżżid student. Matematika 101 jgħid is-Sezzjoni 1 “”huma inti tiftaħ?”” F’dan il-każ, Taqsima 1 risposti li dawn huma miftuħa, tant Matematika 101 jgħidlekx it-taqsima 1 ta iżżidx din istudent. Għal darb’oħra, dijagrammi sekwenza huma għodod kbira fil-bidu minħabba li nuruk u l-klijent tiegħek pass-pass x’għandu jiġri.
Mill-aspett analiżi tal-vista, stajt misjuba matul is-snin li dijagrammi sekwenza huma qawwija ħafna biex tgħin lili jsuq rekwiżiti; speċjalment rekwiżiti li huma diffiċli li ssib. Rekwiżiti User Interface, per eżempju, huma notorji għaliex inti dejjem jidhru li nikseb rekwiżiti li huma biss mhux testable. Rekwiżit UI komuni bħal dan huwa “”din is-sistema għandha tkun faċli għall-utent.”” Kemm għandek sodisfatti kompjuter ħbiberija? Wieħed mill-benefiċċji ta ‘dawn it-tipi ta’ dijagrammi huwa li kull linja li ġejja minn attur li tirrappreżenta persuna, jgħidlek li xi ħaġa fil UI tiegħek irid jipprovdi kapaċità meħtieġa minn dik il-persuna. Fi kliem ieħor, inti tista ‘tuża d-dijagrammi sekwenza biex issuq l-ħtiġiet testable interface għall-utent.
dijagrammi sekwenza huma, għalhekk, tajba għall-wiri x’inhu għaddej, għas-sewqan rekwiżiti, u għall-ħidma mal-klijenti. Dik normalment iwassal għall-mistoqsija, għalkemm, ‘kif ħafna għandek bżonn biex joħolqu? Risposta tiegħi hija, “”sakemm inti tagħmel biżżejjed.”” Inti qed tmur biex issir taf meta inti tagħmel dijagrammi sekwenza li inti tilħaq il-punt fejn int ma konstatazzjoni xi oġġetti ġodda, konstatazzjoni ma xi messaġġi ġodda, u li int ttajpjati l-istess ħaġa aktar u aktar. Fl-eżempju ta ‘Joe tgħaqqad Matematika 101, nitgħallmu li l-proċess ikun l-istess kieku Joe riedu jingħaqdu Istorja 101. Għalhekk, ir-regola ta’ thumb, do dijagramma sekwenza għal kull fluss bażiku ta ‘kull każ użu. Do dijagramma sekwenza ta ‘livell għoli, xenarji riskjużi, u li għandu jkun biżżejjed. Thats kif dijagrammi sekwenza ħafna I do.
li tiftakar hawnhekk, huwa li dijagramma kollaborazzjoni hija biss opinjoni differenti ta ‘xenarju u inti tista’ tmur quddiem u lura bejn dijagrammi sekwenza u d-dijagrammi kollaborazzjoni biex jiksbu l-fehma li l-aħjar turi il-punt tiegħek.
Kultant, inti tista ’tisma’ l-frażi “”dijagrammi interazzjoni.”” Kultant nies se kollettivament jirreferu għal dijagramma kollaborazzjoni u dijagramma sekwenza bħala dijagramma interazzjoni.
klassi Dijagrammi
A klassi hija ġabra ta ‘oġġetti bi struttura komuni, l-imġiba komuni, ir-relazzjonijiet komuni, u semantika komuni. Għandek issib minnhom billi teżamina l-oġġetti fil sekwenza u kollaborazzjoni dijagrammi, u huma rrappreżentati fil-UML bħala rettangolu bi tliet kompartimenti.
Figura 8: Klassijiet
L-ewwel kompartiment jindikaw l-isem tal-klassi, it-tieni turi istruttura tagħha (attributi), u t-tielet turi aġir tagħha (operazzjonijiet). Dawn il-kompartimenti jistgħu jiġu mrażżna, madankollu, sabiex inti tista ‘tara biss l-isem, biss l-isem u l-attributi, jew it-tlieta. Ħaġa waħda inti għandek tkun taf ukoll hija li huwa importanti, meta ismijiet klassijiet, li juża l-vokabolarju tad-dominju u pick standard. Għal dan eżempju, klassijiet tiegħi huma nomi kollha singular li jibdew b’ittra kapitali. Inti tista ‘tagħżel li tagħmel dan b’mod differenti, u li ma jimpurtax. Dak ma kwistjoni hija li qabel il-proġett tiegħek inti pick standard u stick miegħu hekk li kollox huwa konsistenti madwar l-proġett.
Klassi Dijagrammi nuruk-natura statika ta ‘sistema tiegħek. Dawn il dijagrammi juru l-eżistenza ta ‘klassijiet u r-relazzjonijiet tagħhom fil-fehma loġika ta’ sistema. Int ser ikollok dijagrammi klassi ħafna fil-mudell.
L-elementi immudellar UML misjuba fl dijagrammi klassi tinkludi:
Klassijiet u l-istruttura u l-imġiba tagħhom.
relazzjonijiet Assoċjazzjoni, aggregazzjoni, dipendenza, u wirt.
Indikaturi Multipliċità u navigazzjoni
ismijiet Rwol.
Agħti ħarsa lejn l-Figura 9. Din id-dijagramma turi operazzjonijiet (l-imġieba): liema oġġett f’dik il-klassi tista ‘tagħmel. Nsib operazzjonijiet tiegħi billi tħares lejn dijagrammi-interazzjonijiet tiegħi.
Figura 9: Operazzjonijiet
Hawnhekk jien ngħid li jeħtieġu li jkunu kapaċi li titlob lill-maniġer tar-reġistrazzjoni li żżid student li Matematika
101. Li għaddej biex jittraduċi ruħu operazzjoni tissejjaħ “”addCourse.””
L-istruttura ta ‘klassi huwa rappreżentat minn attributi tagħha. Allura kif nista ‘nsib attributi tiegħi? Billi tkellem lill-esperti dominju. Billi tħares lejn ħtiġijiet tiegħi. Fl-eżempju tiegħi, jien jitgħallmu li kull offerta kors għandu numru, post, u kull darba. Dan jittraduċi lil tliet attributi.
klassijiet. (Rappreżentata fil-UML bħala linja li tgħaqqad il-klassijiet relatati ma ‘djamant li jmiss għall-klassi li jirrappreżenta l-sħiħ.)
â € ¢ Dipendenza â € “”forma aktar dgħajfa turi r-relazzjoni bejn klijent u fornitur fejn il-klijent ma jkollux tagħrif semantiku tal-fornitur. A dipendenza jgħid “”I ħtieġa servizzi tiegħek, imma jien ma nafx li inti jeżistu.”” (Rappreżentata fil-UML bħala linja dashed tipponta mill-klijent lill-fornitur.)
Biex issib ir-relazzjonijiet, għal darb’oħra, mmur lura għall dijagramma sekwenza tiegħi. Jekk żewġ oġġetti ħtieġa li “”nitkellmu””, għandu jkun hemm mezz biex jagħmlu dan (jiġifieri, relazzjoni bejn il-klassijiet tagħhom).
I tipikament jibdew u jagħmlu dak kollu assoċjazzjoni. Kif nagħmel analiżi iktar, I jista ‘jsib I jkollhom aggregazzjoni għax jien ser ikollhom biex jieħu kura ta’ relazzjoni ġenitur-wild. Meta niġi fil-fażi tad-disinn, nkun naf li jien ma jista ‘jkollha bżonn assoċjazzjoni għaliex xi ħadd ieħor li jkun ser jgħaddi dak l-oġġett f’waħda mill-metodi tiegħi â € “”so I jagħmluha dipendenza.
Figura 11: Relazzjonijiet
Fil-Figura 11 tara dawn ir-relazzjonijiet. Peress li l-assoċjazzjoni jgħid il-Professur tista ‘tkellem lill-Offerta Kors, u l-Offerta Kors tista’ tkellem lill-Professur. Messaġġi jistgħu jinbdew u d-data jistgħu jiġu mis kwalunkwe direzzjoni. Aggregazzjoni tidher billi jkollu l-djamant lejn l-â € sħiħ “”f’dan il-każ Kors huwa magħmul minn Offerti Kors. Ir-raġuni għal dan aggregazzjoni ikun li tgħid iżviluppaturi tiegħi li jekk huma jiksbu rid ta ‘dan Kors, dawn ser probabbilment għandek tagħmel xi ħaġa speċjali mal-Offerti Kors. Dipendenzi huma murija bħala linja dashed. Huwa qal li l-maniġer tar-reġistrazzjoni tiddependi fuq l-Iskeda Algoritmu li jagħmel xi ħaġa. Il Algoritmu Skeda hija jew parametru għal wieħed mill-metodi jew huwa ddikjarat lokalment minn wieħed mill-Metodi tal-Maniġer Reġistrazzjoni.
Multipliċità u Navigazzjoni
Multipliċità jiddefinixxi kif bosta oġġetti jipparteċipaw fl-relazzjoni. Huwa n-numru ta ‘każijiet ta’ klassi waħda għandhom x’jaqsmu mal okkażjoni waħda mill-klassi l-oħra. Għal kull assoċjazzjoni u l-aggregazzjoni, hemm żewġ deċiżjonijiet multipliċità li jagħmlu: waħda għal kull terminazzjoni tar-relazzjoni. Multipliċità huwa rappreżentat bħala numru u * jintuża biex jirrappreżenta multipliċità ta ‘ħafna.
Figura 12: Multipliċità u n-navigazzjoni
Wieħed Għan Professur huwa relatat għal żero ‘għall-erba Objects Kors Offerta. Wieħed Kors Offerta Għan huwa relatat mal eżattament Għan Professur wieħed. I jużaw dan biex tħares lejn u jiżguraw li din l mankijiet rekwiżiti tiegħi. Nista ‘tkun Offerta Kors u jiġu tim mgħallma minn mazz ta’ professuri? Le, għaliex dan jgħid nista ‘jkollhom biss professur wieħed. Nista ‘nkun professur u tkun fuq leave? Iva, għaliex dan jgħid għandi żero kemm tagħbija possibli kors. I użu multipliċità spiss biex jgħin lili jibdew qabda u l-implimentazzjoni tar-regoli kummerċjali tiegħi. Jekk għandek, per eżempju, regola kummerċjali li tgħid li inti għandu jkollhom mill-inqas 3 studenti u mhux aktar minn 10 għal kors li jiġi offrut fi semestru, dawn in-numri multipliċità tell me stajt inkorporati li regola kummerċjali fis dan il-pjan.
Navigazzjoni huwa muri bi vleġġa, u għalkemm l-assoċjazzjonijiet u l-aggregazzjonijiet huma bi-direzzjonali fil-kontumaċja, ħafna drabi huwa mixtieq li jkun limitat navigazzjoni għad-direzzjoni wieħed. Meta n-navigazzjoni hija ristretta, l arrowhead huwa miżjud ma ‘jindika l-direzzjoni tan-navigazzjoni. Waħda mill-affarijiet I do matul il-fażijiet ta ‘analiżi u d-disinn hu li tħares lejn dak li nixtieq li jkun uni-direzzjonali. Permezz ta ‘tqegħid l-vleġġa fis dan dijagramma, ngħidilhom li l-Maniġer tar-Reġistrazzjoni tista’ tibgħat messaġġ lill-Kors, għaliex taf teżisti l-Kors. Iżda l-Kors m’għandha l-ebda idea li teżisti l-Maniġer Reġistrazzjoni, sabiex il-Kors ma tistax tibda messaġġ. Issa dejta jista ‘fluss bejniethom; per eżempju il-Manager ta ‘Reġistrazzjoni tista’ titlob lill-Kors jekk huwa miftuħ u l-Kors jista ‘jgħid li huwa. Iżda biss il-Manager ta ‘Reġistrazzjoni tista’ tibda din il-konverżazzjoni.
Ovvjament l-għan hawnhekk huwa li tikseb kif ħafna vleġeġ kif inti tista ‘mill-ħin li inti stajt lest tfassil, għaliex dan huwa sistema ħafna aktar faċli biex jinżamm Wirt hija murija bil-trijanglu. Dan juri li l-Professur huwa Utenti Reġistrazzjoni, kif inhu l-Istudenti. Issa, kelma ta ‘twissija. Wirt huwa utli, madankollu, l-għan huwa li ma jużawx wirt kemm is-sistema tiegħek se jippermettu. Stajt tidher xi sistemi verament brutali fejn huma kellhom fuq il-wirt 17-livelli fil-fond. Jekk huma bidlu ħaġa waħda, deher diżastru. Allura l-istat ta ‘thumb huwa li tuża wirt biss meta inti verament do jkollhom sitwazzjoni wirt.
Istat Dijagrammi Tranżizzjoni
Dijagramma transizzjoni istat turi l-istorja tal-ħajja ta ‘klassi partikolari. Dan juri l-avvenimenti li jikkawżaw tranżizzjoni minn stat għal ieħor, u l-azzjonijiet li jirriżultaw minn bidla stat.
Figura 14: Dijagramma tranżizzjoni Istat
I użu dijagrammi tranżizzjoni istat għall-klassijiet oġġett li tipikament għandhom ħafna imġiba dinamika. Il-buttuna hija fuq € â | il-buttuna huwa off; Jien ma jmur biex tagħmel chart stat għal dan. Iżda klassijiet oġġett li jkollha lott ta ‘imġiba dinamika, jien probabbilment se jkollha tħares fil-istati tal-oġġetti.
Nibda billi turi stat, li huwa trijanglu tond. I jista ‘jkollhom istati bidu, u nista’ jkollhom l-istati waqfien, li huma murija bħala barrin għajnejn. I jista ‘jkollhom ukoll transizzjonijiet bejn l-istati, jew transizzjonijiet gwardja (affarijiet li jiġri meta biss meta kondizzjoni hija vera), jew affarijiet li jiġri meta jien ġewwa l-istat. I ħarsa lejn din dijagramma u tara t-tranżizzjoni dijagramma istat għal offerta kors. Dan jibda fl-istat inizjalizzazzjoni, u jien joqogħdu f’dak l-istat sal I nikseb “”żid student”” messaġġ. Meta niġi dak il-messaġġ, I sett għadd tiegħi ta ‘studenti għal żero u jien transizzjoni għall-istat Open. Int ser ikollok tara fil-Figura 14 li għandi dħul, u r-raġuni għaliex huwa hemm li għandi żewġ modi ta ‘jkollna fis-istat. Hija tgħid li l-ebda kwistjoni kif inti tidħol fis-istat, nixtieq li tirreġistra l-istudent. Meta I ħruġ f’dak l-istat, il-bidliet għadd li jżommu rekord tan-numru ta ‘studenti fil-kors. I tista ‘żżomm żżid istudenti sakemm nasal sa 10, u mbagħad mmur għall-istat Agħlaq. Ladarba l-kors huwa ffinalizzat, jien transizzjoni għall-istat waqfien. Ma jimpurtax fejn I am imbagħad, jekk niġi il Ikkanċella tranżizzjoni Avveniment, jien jinnotifikaw istudenti tiegħi u mbagħad transizzjoni għall-istat waqfien.
Għal klassijiet oġġett li jkollha lott ta ‘mġiba dinamika, huwa ukoll jiswa li tagħmel dijagramma istat biex jiksbu jimmaniġġaw fuq dak kollu li għandu jiġri. Staqsi lilek innifsek dak li jiġri meta niġi messaġġ? X’għandi nagħmel meta nasal il-messaġġ? Dak messaġġi li jien tibgħat? A lott ta ‘dawk il-messaġġi jsiru operazzjonijiet tal-klassi oġġett, bħal f’dan l-eżempju fejn żid student hija operazzjoni. A lott ta ‘dawn l-azzjonijiet, bħall-iffissar tal-għadd, inkrementazzjoni l-għadd, iċċekkjar tal-għadd, dawn kollha jsiru operazzjonijiet privati ta’ dik il-klassi oġġett partikolari u dijagramma stat huwa fejn nara li.
Kif tkun taf jekk għandek klassi oġġett dinamiku? Għal darb’oħra, mur lura għall-dijagrammi sekwenza. Jekk għandek xi klassi oġġett li fuq lott ta ‘dijagrammi sekwenza u huwa jkollna u jibgħat ħafna ta’ messaġġi, li l-indikazzjoni tajba huwa klassi oġġett pjuttost dinamiku u għandu probabilment jkollhom chart stat għal dan. Wkoll għal aggregazzjonijiet, fejn inti għandek l-sħiħ tal-partijiet tagħha, I do chart stat għal kull kollu aggregat. Nagħmel dan l-aktar minħabba li sħaħ aggregat huwa ta ‘spiss responsabbli għall-ġestjoni tal-messaġġi, li jagħmilha dinamiku.
dijagrammi komponent
Naturalment ebda sistema jistgħu jinbnew mingħajr ma jittieħdu in kunsiderazzjoni l-dinja fiżika. Li meta dijagrammi tal-komponenti jaqgħu fil. Huma jintużaw biex juru l-organizzazzjonijiet u d-dipendenzi bejn komponenti tas-softwer, inklużi l-komponenti ta ‘sors tal-kodiċi, komponenti ħin run, jew komponent eżekutibbli. Komponenti huma turi bħala rettangolu kbir b’żewġ rettangoli iżgħar fuq il-ġenb, kif jidher fil-Figura 15.
Figura 15: Komponenti
Dawk l-affarijiet rawnd jirrappreżentaw interfaċċji (spiss imsejħa notazzjoni lollipop). F’dan il-każ, dawn juru li l-Register.exe hija dipendenti fuq l-interfaces kemm lill-Course.dll u l People.dll. Dan ifisser li jekk dawn l-interfaces jinbidlu, se impatt l Register.exe. Naf li hemm din ir-regola meta int interfaċċji bini li tgħid “”thou ma għandhomx jibdlu l-interface.”” Iżda ħadd ma attwalment jaħdmu meta din ir-regola tiġi infurzata? Din id-dijagramma tgħidilna dak interfaces huma użati mill dak li executables qed jitħaddmu fuq il-proċessuri tiegħi.
Figura 16: Dijagramma Utilizzazzjoni
L-estensjoni UML
L-aħħar ħaġa li nixtieq li jkun enfasizzat dwar il-UML huwa li tista ‘tiġi estiża. Meta mibnija l-UML, huma b’mod għaqli ħafna induna li ma kien hemm ebda mod kif huma jistgħu joħolqu notazzjoni li tista ‘jekk jogħġbok kollha tal-poplu kollu tal-ħin. Allura dawn tawna l-kunċett ta isterjotip. A isterjotip tgħid I tista ‘tieħu element immudellar bażiku u jagħtiha aktar sens. Isterjotipi jistgħu jintużaw biex jikklassifikaw u testendi l-assoċjazzjonijiet, relazzjonijiet wirt, klassijiet, u komponenti.
Figura 17: Web isterjotip eżempju
Figura 17 turi d-dijagramma ta ‘sterjotipi Web tagħna. A paġna tal-Web tipikament tkun għalf li timxi fuq is-server u l-għalf li timxi fuq il-klijent. Jekk int bini applikazzjonijiet Web bbażati fuq, x’inhu għaddej fuq il-klijent u s-server huwa ta ‘importanza vitali. Allura aħna għandna sett sħiħ ta ‘sterjotipi li juru li. Ir-roti ftit jirrappreżentaw affarijiet li jimxu fuq is-server. Hekk biss billi tħares lejn din dijagramma wieħed I jista ‘jara dak timxi fuq is-server, dak timxi fuq il-klijent, u dak l-oġġetti tan-negozju li jkollhom jittrattaw.

“——————————————————————————————————————————————————

Ondersteuning vertaling: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”Die UML is die standaard taal vir die spesifiseer, visualisering, die bou van, en die dokumentasie van al die artefakte van ‘n sagteware stelsel.””
Aktiwiteit Diagramme
Die logiese plek om te begin loop deur ‘n paar van die UML diagramme is deur te kyk na aktiwiteit diagramme.
Figuur 2: Aktiwiteit diagram
Aktiwiteit diagramme toon die vloei van beheer. Soos in figuur 2, kan jy aktiwiteite verteenwoordig as afgerond reghoeke sien. Aktiwiteite is tipies aksie state â € “”dat oorgang outomaties na die volgende toestand na die aksie is voltooi. Die ingevul sirkel verteenwoordig die begin van die aktiwiteit diagram â € “”waar die vloei van beheer begin. Oorgange getoon as pyle te wys hoe jy beweeg van aktiwiteit aktiwiteit. Synchronisatie bars wys hoe aktiwiteite gebeur in parallel. Ek kan ‘n oorgang wat sê waak “”Ek wil hê jy moet gaan na hierdie aktiwiteit slegs indien hierdie toestand is waar,”” en ek kan jou wys waar dit tot stilstand kom. Nou as jy ‘n sekere ouderdom is, sal jy waarskynlik kyk na hierdie aktiwiteit diagram en dink, “”hmm â € |. Wat lyk soos ‘n vloeidiagram”” En dit is presies wat dit is, behalwe as ek dit nie is besig met af by die ontwikkeling vlak. Tipies, ek gebruik ‘n aktiwiteit diagram redelik vroeg in my analise en ontwerpproses om sake workflow wys. Ek sal hulle ook gebruik om aan te toon waar elkeen van my gebruik gevalle kan wees in ‘n aktiwiteit om te illustreer wat gebruik geval het om te gebeur. Ek gebruik ook aktiwiteit diagramme te wys hoe dinge vloei tussen my gebruik gevalle.
Maar een van die groot dinge oor die UML is sy veelsydigheid. Dus, terwyl ek gebruik aktiwiteit diagramme aan die begin van die lewensiklus, kan ander dit te gebruik in ‘n ander fase heeltemal. Ek het gesien hoe mense gebruik aktiwiteit diagramme af by die ontwerp vlak waar hulle het ‘n baie ingewikkelde stel algoritmes vir ‘n bepaalde klas. En baie mense gebruik dit om die vloei tussen die metodes van ‘n klas te wys.
die sisteem. Akteurs verteenwoordig as stok figure.
Figuur 4: Akteurs
Die voorbeeld wat ek gewerk het vir hierdie inleiding tot UML is ‘n bietjie model van ‘n kursus registrasie stelsel. So in hierdie geval, die eerste ding wat ek sou doen as die begin van my analise proses is om te vra, “”wat gaan om met hierdie stelsel?””
Vir die kursus registrasie model, ek het ‘n registrateur, ‘n professor, en ‘n student. Ek het ook ‘n eksterne faktuur stelsel. Dit rekeningstelsel ook kwalifiseer as ‘n akteur. (Sien, ‘n akteur nie ‘n persoon â € “”dit is iets wat in wisselwerking met die stelsel, maar is buite die stelsel wees.)
A gebruik geval is ‘n reeks van verwante transaksies uitgevoer word deur ‘n akteur in die stelsel in ‘n dialoog. Of, om dit in Engels te stel, ‘n gebruik geval is ‘n stuk van funksionaliteit. En hier is die sleutel: dit is nie ‘n sagteware module â € “”dit is iets wat waarde bied aan die akteur.
Gebruik gevalle word as ovale, en die maklikste manier om dit te vind is om te kyk na elkeen van jou akteurs en vra jouself af waarom hulle wil die stelsel gebruik. In my geval, is my registrateur gaan om die kurrikulum te handhaaf, my professor gaan ‘n rooster te vra, my student hou die skedule, en my faktuur stelsel ontvang die faktuur inligting. So ek my gebruik gevalle te skep deur te kyk na dit uit die kliënt oogpunt en vra, “”So, meneer stelsel akteur, waarom wil jy die stelsel te gebruik? Watter waarde hierdie stelsel te verskaf vir jou?””
Die volgende stap, nadat jy geïdentifiseer hoe jou akteurs sal interaksie met die stelsel, is moenie jou gebruik gevalle dokumenteer. Elke gebruik geval moet gedokumenteer saam met die vloei van gebeure, en dit word gedoen vanuit die oogpunt van die akteur se. Dit moet volledig wat die stelsel moet voorsiening maak om die akteur wanneer die gebruik geval uitgevoer word. Tipies sal dit dinge soos hoe die gebruik geval begin en eindig wys. Watter dinge doen wat gebruik maak saak hoef te doen? Jy sal die normale vloei van gebeure (wat ek noem die “”gelukkige dae”” scenario), waar alles werk het. Dan sal jy die abnormale vloei van gebeure, die “”reënerige dag”” scenario kry. Wat gebeur wanneer die stelsel nie werk nie? Ek het gevind deur die dokumentasie van my vloei van gebeure dat ek altyd begin met die gelukkige dae scenario.
Neem as voorbeeld, loop tot ‘n outomatiese tellermasjien. Jy loop tot by die OTM en voeg jou kaart. Dit vra vir jou PIN-nommer. Jy gaan dit, en jy gevra word wat jy graag wil doen. Jy sê: “”Ek wil ‘n bietjie geld.”” Dit vra waar die geld geneem moet word uit. Jy vertel om dit te neem van jou betaalrekening. Dit vra hoeveel. Jy sê $ 100,00. Dan gebeur magie â € | dit gee jou $ 100,00. Dan vra dit as jy ‘n ander transaksie wil. Jy sê nee. Dit gee jou jou kaart terug, gee jou ‘n kwitansie, en die transaksie is verby. Dit is die gelukkige dag scenario.
Tweede scenario. Gaan julle op na die OTM, voeg jou kaart, en tik jou PIN. Die OTM vertel jou dis die verkeerde PIN. Jy gaan jou nommer weer. Weereens jy word vertel dat die PIN is verkeerd. Jy In my loopbaan registrasie voorbeeld, byvoorbeeld, kan jy sien dat daar ‘n baie “”As X dan Y”” werkstromen. Dit is waar jy jou kliënte om jou te help wil. Aan ooreenkoms beteken vroeë jou kliënt verstaan hierdie scenario’s en sê: “”Ja, dit is wat ons wil hê.”” Gebruik gevalle is ‘n goeie manier om te verseker dat dit wat jy bou is regtig wat die kliënt wil, omdat hulle die akteurs, die gebruik gevalle, en die verhouding tussen hulle te wys.
Figuur 5: Gebruik geval diagram
Dus het ons ‘n groot diagram wat grafies wys my wat? Die antwoord is eenvoudig â € “”dit is ‘n groot diagram wat ‘n goeie oorsig van die stelsel toon. Dit wys wat buite die stelsel (akteurs) en die funksies wat die stelsel (gebruik gevalle) moet voorsiening maak. As daar ‘n nalatenskap stelsel wat jy nodig het om in ag te neem, hier is waar jy gaan met dit. Dwing my om te werk met hierdie tipe van koppelvlakke baie vroeg in die projek beteken dat ek nie sal gekonfronteer word met die vooruitsig van wag totdat kodering begin om uit te vind hoe ek gaan dit swart boks wat ek nie kan verander om te praat .
Nog ‘n ding wat jy moet weet oor die gebruik gevalle is die gebruik geval besef. Dit is die “”hoe”” van die gebruik geval. Dit is gewoonlik ‘n emmer wat drie verskillende tipes diagramme bevat: volgorde diagramme, samewerking diagramme, en ‘n klasdiagram wat ons noem ‘n uitsig oor deelnemende klasse. Gebruik geval realisasies is basies ‘n manier om saam te groepeer ‘n aantal artefakte wat verband hou met die ontwerp van ‘n gebruik geval.
volgorde Diagramme
Volgorde diagramme toon voorwerp interaksies wat in ‘n tydsverloop. Ek kan die vloei van gebeure te gebruik om te bepaal watter voorwerpe en interaksie ek sal nodig hê om die funksies wat deur die vloei van gebeure te bereik.
Figuur 6: Volgorde diagram
Figuur 6 toon hoe ‘n student suksesvol raak by ‘n kursus. Die student (kom ons noem hom Joe) vul in ‘n paar inligting en dien die vorm. Die vorm praat dan aan die bestuurder en sê “”voeg Joe om Wiskunde 101.”” Die bestuurder vertel Wiskunde 101 dat dit aan ‘n student toe te voeg. Wiskunde 101 sê vir Afdeling 1 “”is jy oop te maak?”” In hierdie geval, Afdeling 1 antwoorde dat hulle oop, sodat Wiskunde 101 vertel artikel 1 van hierdie student by te voeg. Weereens, ry diagramme is groot gereedskap in die begin, want hulle wys jy en jou kliënt stap-vir-stap wat moet gebeur.
Uit ‘n ontleding oogpunt, het ek gevind het oor die jare wat volgorde diagramme is baie sterk in my gehelp ry vereistes; veral vereistes wat moeilik om te vind. Gebruikerskoppelvlak vereistes, byvoorbeeld, is berug omdat jy altyd lyk vereistes wat net nie toetsbaar te kry. ‘N Algemene UI vereiste soos hierdie is “”hierdie stelsel sal gebruikersvriendelik wees.”” Hoeveel van julle het ‘n vriendelike rekenaar ontmoet? Een van die voordele van hierdie tipe diagramme is dat elke lyn kom van ‘n akteur wat ‘n persoon verteenwoordig, sê jy dat daar iets in jou UI moet ‘n vermoë wat nodig is deur daardie persoon voorsien. Met ander woorde, kan jy ry diagramme gebruik om toetsbare gebruikerskoppelvlak vereistes uit te dryf.
Volgorde diagramme is dus goed vir die vertoon van wat aangaan nie, want jy ry uit vereistes, en vir die werk met kliënte. Dit lei gewoonlik tot die vraag is egter hoeveel het jy nodig om te skep? My antwoord is, “”totdat jy genoeg doen.”” Jy gaan om uit te vind wanneer jy ry diagramme dat jy ‘n punt bereik waar jy nie enige nuwe voorwerpe is om nie enige nuwe boodskappe vind nie, en dat jy dieselfde ding tik oor en oor. In die voorbeeld van Joe by Wiskunde 101, leer ons dat die proses dieselfde sou wees as Joe wou Geskiedenis 101. Dus, reël aan te sluit, doen ‘n reeks diagram vir elke basiese vloei van elke gebruik geval. Doen ‘n reeks diagram vir ‘n hoë-vlak, riskante scenario, en dat moet genoeg wees. Dit is hoeveel volgorde diagramme ek doen.
om hier te onthou, is dat ‘n samewerking diagram is net ‘n ander siening van ‘n scenario en jy kan heen en weer gaan tussen volgorde diagramme en samewerking diagramme om die siening dat die beste illustreer jou punt te kry.
Soms, kan jy hoor die frase “”interaksie diagramme.”” Soms het mense sal gesamentlik verwys na ‘n samewerking diagram en ‘n reeks diagram as ‘n interaksie diagram.
klasdiagramme
‘N Klas is ‘n versameling van voorwerpe met ‘n gemeenskaplike struktuur, gemeenskaplike gedrag, gemeenskaplike verhoudings, en algemene semantiek. Jy kry hulle deur die ondersoek van die voorwerpe in volgorde en samewerking diagramme, en hulle verteenwoordig in die UML as ‘n reghoek met drie kompartemente.
Figuur 8: Klasse
Die eerste kompartement toon die klasnaam, die tweede toon die struktuur (eienskappe), en die derde toon sy gedrag (operasies). Hierdie kompartemente kan onderdruk word, maar so dat jy net die naam, net die naam en die eienskappe, of al drie kan sien. Een ding moet jy ook weet, is dat dit belangrik is, toe noem klasse, om die woordeskat van die domein en haal ‘n standaard. Vir hierdie geval, my klasse is al enkele Woorde wat begin met ‘n hoofletter. Jy kan kies om dit anders te doen, en dit maak nie saak. Wat beteken saak is dat voor jou projek wat jy ‘n standaard haal en vashou aan dit, sodat alles is konsekwent oor die projek.
Klasdiagramme wys jou die statiese aard van jou stelsel. Hierdie diagramme toon die bestaan van klasse en hul verhoudings in die logiese siening van ‘n stelsel. Jy sal baie klasdiagramme in ‘n model het.
Die UML modellering elemente in klasdiagramme insluit:
Klasse en hul struktuur en gedrag.
Vereniging, samevoeging, afhanklikheid, en erfenis verhoudings.
Veelvuldigheid en navigasie aanwysers
Rol name.
Neem ‘n blik op Figuur 9. Hierdie diagram toon bedrywighede (gedrag): wat ‘n voorwerp in daardie klas kan doen. Ek vind my bedrywighede deur te kyk na my interaksies diagramme.
Figuur 9: Bedryf
Hier ek sê dat ek nodig het om in staat wees om die registrasie bestuurder vra om ‘n student te Math voeg
101. Dit gaan sit in ‘n operasie genaamd “”addCourse.””
Die struktuur van ‘n klas word verteenwoordig deur sy eienskappe. So, hoe kan ek my eienskappe vind? Deur te praat met domein kundiges. Deur te kyk na my vereistes. In my voorbeeld, ek verneem dat elke kursus aanbod het ‘n nommer, ‘n plek en ‘n tyd. Dit kom neer uit drie eienskappe.
klasse. (Wat in die UML as ‘n lyn verbind die verwante klasse met ‘n diamant langs die klas wat die geheel.)
â € ¢ Afhanklikheid â € “” ‘n swakker vorm wat die verhouding tussen ‘n kliënt en ‘n verskaffer waar die kliënt semantiese kennis van die verskaffer het nie. A afhanklikheid sê: “”Ek het jou dienste, maar ek weet nie wat jy bestaan nie.”” (Wat in die UML as ‘n stippellyn wys van die kliënt aan die verskaffer.)
Om verhoudings te vind, weer, gaan ek terug na my volgorde diagram. As twee voorwerpe moet “”praat””, moet daar ‘n manier om dit te doen (dit wil sê ‘n verhouding tussen hulle klasse).
Ek begin gewoonlik uit en maak alles ‘n vereniging. Soos ek doen meer analise, kan ek vind ek ‘n samevoeging want ek gaan hê om te sorg vir ‘n ouer-kind-verhouding. Wanneer ek in die ontwerpfase, vind ek uit dat ek ‘n vereniging nie dalk nodig omdat iemand anders gaan daardie voorwerp te slaag in een van my metodes â € “”so ek maak dit ‘n afhanklikheid.
Figuur 11: Verhoudings
In Figuur 11 sien jy hierdie verhoudings. As vereniging sê die professor kan die kursus aanbod, en die kursus aanbod praat met die professor kan praat. Boodskappe kan begin en data kan vloei uit enige rigting. Samevoeging getoon deur met die diamant in die rigting van die hele â € “”in hierdie geval ‘n kursus is saamgestel uit Kursus wat daarby behoort. Die rede hiervoor samevoeging sou wees om my ontwikkelaars vertel dat as hulle ontslae te raak van hierdie kursus, sal hulle waarskynlik iets spesiaals met die kursus aanbod te doen. Afhanklikhede word as ‘n stippellyn. Dit sê dat die registrasie bestuurder hang af van die Bylae Algoritme om iets te doen. Die Bylae Algoritme is óf ‘n parameter na een van die metodes of plaaslik verklaar deur een van die metodes van die Registrasie Bestuurder.
Veelvuldigheid en Navigation
Veelheid definieer hoeveel voorwerpe deelneem aan ‘n verhouding. Dit is die aantal gevalle van een klas wat verband hou met ‘n afskrif van die ander klas. Vir elke vereniging en samevoeging, is daar twee verskeidenheid besluite te maak: een vir elke einde van die verhouding. Veelheid word voorgestel as ‘n nommer en ‘n * word gebruik om ‘n verskeidenheid van baie verteenwoordig.
Figuur 12: Multiplicity en navigasie
Een Professor voorwerp wat verband hou met nul-tot-vier kursus aanbod voorwerpe. Een kursus aanbod voorwerp wat verband hou met presies een Professor voorwerp. Ek gebruik hierdie om te kyk na en te verseker dat hierdie hanteer my vereistes. Kan ek ‘n kursus aanbod en word span geleer deur ‘n klomp van die professore? Nee, want dit sê ek kan net een professor. Kan ek ‘n professor en op sabbatsverlof? Ja, want dit sê ek het ‘n nul as moontlik verloop vrag. Ek gebruik veelheid dikwels om my te help begin opneem van en die uitvoering van my besigheid reëls. As jy byvoorbeeld ‘n besigheid reël wat sê jy moet ten minste 3 studente en nie meer as 10 vir ‘n kursus aangebied gaan word in ‘n semester het, hierdie verskeidenheid nommers vir my sê ek het opgeneem dat sake reël in hierdie plan.
Navigasie getoon deur ‘n pyl, en hoewel verenigings en riffen is bidirectionele by verstek, is dit dikwels wenslik na navigasie een rigting beperk. Wanneer navigasie beperk, is ‘n pylpunt by die navigasie-rigting aan te dui. Een van die dinge wat ek doen in die analise en ontwerp fases is kyk na wat ek wil uni-directional te wees. Deur die pyl in die diagram, ek sê dat die Registrasie Bestuurder ‘n boodskap kan stuur om die kursus, want dit weet die Kursus bestaan. Maar die kursus het geen idee gehad dat die Registrasie Bestuurder bestaan, sodat die kursus kan ‘n boodskap nie inisieer. Nou data kan vloei tussen hulle; byvoorbeeld die Registrasie Bestuurder kan die kursus te vra of dit oop en die kursus kan sê dat dit is. Maar net die Registrasie Bestuurder kan die gesprek begin.
Dit is duidelik dat die doel hier is om soveel pyle kry as wat jy kan teen die tyd dat jy klaar is met die ontwerp, want dit is ‘n baie makliker stelsel Erfenis handhaaf getoon met ‘n driehoek. Dit dui aan dat die professor is ‘n gebruiker registrasie, soos die student. Nou, ‘n woord van waarskuwing. Erfenis is nuttig, maar die doel is soveel erfenis as jou stelsel sal toelaat om nie te gebruik. Ek het ‘n paar baie wrede stelsels waar hulle geërwe 17-vlakke diep gesien. As hulle een ding verander, dit het ‘n ramp. So het die reël is om erfenis te gebruik slegs wanneer jy werklik doen het ‘n erfenis situasie.
Staat Oorgang Diagramme
‘N staat oorgang diagram toon die lewe geskiedenis van ‘n gegewe klas. Dit wys die gebeure wat ‘n oorgang veroorsaak van een toestand na ‘n ander, en die aksies wat die gevolg is van ‘n toestand verandering.
Figuur 14: Staat oorgang diagram
Ek gebruik die staat oorgang diagramme vir voorwerp klasse wat tipies ‘n baie dinamiese gedrag. Die knoppie is op ‘n € | die knoppie af; Ek is nie van plan om ‘n toestand grafiek doen daarvoor. Maar voorwerp klasse wat ‘n baie dinamiese gedrag het, is ek seker sal moet kyk na die lande van die voorwerpe.
Ek begin deur te wys ‘n toestand, wat ‘n afgeronde driehoek. Ek kan begin state het, en ek kan stop state, wat getoon as bulle oë het. Ek kan ook ‘oorgange tussen state, of wag oorgange (dinge wat gebeur wanneer net vir ‘n toestand is waar), of dinge wat gebeur wanneer ek binne die staat. Ek kyk na die diagram en sien die staat oorgang diagram vir ‘n kursus aanbied. Dit begin in die inisialisering staat, en ek bly in daardie toestand totdat ek ‘n “”add student”” boodskap kry. Toe ek die boodskap kry, ek het my Telling van studente aan nul en ek oorgang na die Open staat. Jy sal sien in Figuur 14 dat ek ‘n inskrywing, en die rede waarom dit is daar dat ek twee maniere om in daardie staat. Dit sê dat dit nie saak hoe jy na die stand kom, ek wil hê jy moet die student registreer. Toe ek daardie toestand verlaat, die telling veranderinge om tred te hou van die aantal studente in die loop te hou. Ek kan hou die toevoeging van studente totdat ek om 10 te kry, en dan gaan ek na die buurt staat. Sodra die kursus afgehandel is, ek oorgang na die stop stand. Maak nie saak waar ek dan, as ek die styl Event oorgang, ek stel my studente en dan oorgang na die stop stand.
Vir voorwerp klasse wat ‘n baie dinamiese gedrag het, is dit die moeite werd om ‘n toestand diagram om ‘n handvatsel te kry oor alles wat gebeur het. Vra jouself wat gebeur wanneer ek ‘n boodskap te kry? Wat doen ek as ek die boodskap kry? Wat boodskappe te Ek het om te stuur? Daar is baie van die boodskappe word bedrywighede van die objekklas, soos in hierdie voorbeeld waar voeg ‘n student ‘n operasie. Baie van hierdie aksies, soos die opstel van die telling, die verhoog die telling, die nagaan van die telling, alhoewel hulle almal geword private bedrywighede van daardie spesifieke objekklas en ‘n toestand diagram is waar ek dit sien.
Hoe weet jy as jy ‘n dinamiese objekklas? Weereens, gaan terug na die volgorde diagramme. As jy ‘n objekklas dis op ‘n baie volgorde diagramme en dit raak en stuur ‘n baie boodskappe, dit is ‘n goeie aanduiding is dit ‘n redelik dinamiese objekklas en dit moet waarskynlik ‘n toestand grafiek daarvoor. Ook vir riffen, waar jy die hele van sy dele, ek doen ‘n toestand grafiek vir elke totaal geheel. Ek doen dit meestal omdat dit totaal geheel is dikwels verantwoordelik vir die bestuur van die boodskap wat dit dinamiese maak.
komponent diagramme
Natuurlik geen stelsel gebou kan word sonder inagneming van die fisiese wêreld. Dit is waar komponent diagramme kom. Hulle word gebruik om die organisasies en afhanklikhede illustreer onder sagteware komponente, insluitende bronkode komponente, hardloop tyd komponente, of ‘n uitvoerbare komponent. Komponente is programme wat as ‘n groot reghoek met twee kleiner reghoeke aan die kant, soos gesien in Figuur 15.
Figuur 15: komponente
Diegene ronde dinge verteenwoordig koppelvlakke (dikwels genoem Lollipop notasie). In hierdie geval, hulle toon dat die Register.exe is afhanklik van koppelvlakke vir beide die Course.dll en die People.dll. Dit beteken dat as die koppelvlakke te verander, sal dit die Register.exe impak. Ek weet dat daar is hierdie reël wanneer jy die bou van koppelvlakke wat sê: “”U sal die koppelvlak nie verander nie.”” Maar nie almal eintlik werk waar daardie reël afgedwing? Hierdie diagram vertel ons wat koppelvlakke word deur wat executables loop op my verwerkers.
Figuur 16: Ontplooiing diagram
Die uitbreiding van UML
Die laaste ding wat ek wil beklemtoon oor die UML is dat dit kan uitgebrei word. Toe hulle die UML gebou, hulle baie voorspoedig besef dat daar geen manier waarop hulle kan ‘n notasie wat al die mense kan tevrede al die tyd te skep was. So het hulle ons die konsep van ‘n stereotipe. A stereotipe sê ek kan ‘n basiese model element te neem en gee dit meer sin. Stereotipes kan gebruik word om te klassifiseer en uit te brei verenigings, erfenis verhoudings, klasse, en komponente.
Figuur 17: Web stereotipe voorbeeld
Figuur 17 toon die diagram van ons Web stereotipes. ‘N webblad het tipies dinge wat loop op die bediener en dinge wat loop op die kliënt. As jy die bou van ‘n web-gebaseerde programme, wat uitgevoer word op die kliënt en die bediener is van kardinale belang. So het ons ‘n hele reeks van stereotipes wat wat wys. Die klein wiele verteenwoordig dinge wat uitgevoer word op die bediener. Dus net deur te kyk na hierdie een diagram Ek kan sien wat loop op die bediener, wat loop op die kliënt, en wat besigheid voorwerpe wat hulle te doen het met.

“——————————————————————————————————————————————————

përkthim Support: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”The UML është gjuha standarde për specifikimin, visualizing, ndërtimin, dhe dokumentuar të gjitha objekte të një sistemi software.””
Aktiviteti Diagramet
Vendi logjike për të filluar duke ecur nëpër disa diagrame UML është duke shikuar në diagrame të aktivitetit.
Figura 2: Aktiviteti diagram
diagrame Aktiviteti tregojnë rrjedhën e kontrollit. Siç ilustrohet në Figurën 2, ju mund të shihni aktivitete të përfaqësuara si rectangles harmonishëm. Aktivitetet janë zakonisht shtetet e veprimit â € “”thuhet se tranzicioni automatikisht në fazën e ardhshme pas veprimit është i plotë. E plotësuar rrethin paraqet fillimin e diagramit aktivitetit â € “”ku rrjedha e fillon të kontrollit. Transitions treguar si shigjeta tregojnë se si ju lëvizin nga aktiviteti me aktivitetin. bare sinkronizimi tregojnë se si aktivitetet të ndodhë në mënyrë paralele. Unë mund të ruajnë një tranzicion që thotë “”Unë dua që ju të shkoni me këtë aktivitet, vetëm nëse kjo gjendje është e vërtetë,”” dhe unë mund të ju tregojnë ku ndalet. Tani në qoftë se ju jeni një moshë të caktuar, ju do të shikoni në këtë diagram aktivitetit dhe mendoj, “”hmm â € |. Që duket si një tabelë e rrjedhës së”” Dhe kjo është pikërisht ajo që është, përveç unë nuk jam duke bërë atë në nivelin e programimit. Në mënyrë tipike, I use një diagram aktivitet mjaft herët në time procesin e analizës dhe të projektimit për të treguar punës biznesit. Unë gjithashtu do të përdorin ato për të treguar se ku secila prej rasteve të përdorimit të mi mund të jetë në një aktivitet për të ilustruar atë rast përdorimi duhet të ndodhë. Unë gjithashtu e përdorin diagramet e aktivitetit për të treguar se si rrjedhin gjërat në mes të rasteve të përdorimit të mi.
Por një nga gjërat e mëdha për UML është shkathtësi e saj. Kështu, ndërsa unë e përdorin diagramet e aktivitetit në fillim të ciklit te jetes, të tjerët mund t’i përdorë ato në një fazë tjetër krejtësisht. Unë kam parë njerëz përdorin aktiviteti diagramet në nivelin e projektimit, ku ata kishin një grup shumë të komplikuar e algoritmeve për një klasë të caktuar poshtë. Dhe shumë njerëz përdorin ato për të treguar rrjedhën mes metodat e një klase.
sistemi. Aktorët janë të përfaqësuara si të figurave shkop.
Figura 4: Aktorët
Shembulli që kam punuar për këtë hyrje në UML është një model i vogël i sistemit të regjistrimit kurs. Pra, në këtë rast, gjëja e parë që do të bëni kur fillon procesi im analiza është që të pyesni, “”i cili do të bashkëveprojnë me këtë sistem?””
Për modelin e regjistrimit të kursit, unë kam një gjendjes civile, një profesor dhe një student. Unë gjithashtu kanë një sistem të jashtëm të faturimit. Ky sistem i faturimit të kualifikohet si një aktor. (Shih, një aktor nuk duhet të jetë një person i â € “”është çdo gjë që ndërvepron me sistemin, por është jashtë sistemit.)
Një rast përdorimi është një sekuencë e transaksioneve të lidhura të kryera nga një aktor në sistemin në një dialog. Ose, për ta vënë atë në gjuhën angleze, një rast përdorimi është një copë e funksionalitetit. Dhe këtu është çelësi: nuk është një modul software â € “”kjo është diçka që ofron vlera të aktorit.
Përdorimi raste janë treguar si ovale, dhe mënyra më e lehtë për të gjetur ata është që të shikojmë në secilin nga aktorët tuaj dhe pyesni veten pse ata duan të përdorin sistemin. Në rastin tim, regjistruesi im është duke shkuar për të ruajtur programin mësimor, profesori im do të kërkojë një regjistër, studenti im mban orarin, dhe sistemi im faturimit merr informacionin e faturimit. Kështu që unë krijoj raste mia përdorimit duke shikuar në atë nga pika e konsumatorit të parë dhe duke i kërkuar “”, kështu që, aktori sistemi i zoti, pse nuk ju duan të përdorin sistemin? Çfarë vlera ka ky sistem të sigurojë për ju?””
Hapi i ardhshëm, një herë ju keni identifikuar se si aktorët e tua do të ndërveprojnë me sistemin, është për ta bërë të dokumentuar raste tuaj të përdorimit. Çdo rast përdorimi duhet të dokumentohen me rrjedhën e ngjarjeve, dhe kjo është bërë nga pika e aktorit të parë. Duhet detaje se çfarë sistemi duhet të sigurojë për aktorin kur rasti përdorimi është ekzekutuar. Në mënyrë tipike kjo do të tregojë gjëra të tilla si se si fillon rast përdorimi dhe përfundon. Cilat gjëra nuk se rasti përdorimi duhet të bëni? Ju do të keni rrjedhën normale të ngjarjeve (asaj që unë e quaj skenar “”ditë të lumtur””), ku çdo gjë punon. Pastaj ju do të merrni rrjedhën e ngjarjeve jonormale, e “”ditë me shi”” skenar. Çfarë ndodh kur sistemi nuk funksionon? Unë e kam gjetur duke dokumentuar rrjedhën time të ngjarjeve që unë gjithmonë të fillojë me lumtur skenar ditë.
Merrni si shembull, duke ecur deri në një makinë automatike parash. Ju ecin deri në ATM dhe të futur kartën tuaj. Ajo e pyet për numrin tuaj PIN. Ju shkruani atë, dhe ju jeni duke kërkuar atë që ju dëshironi të bëni. Ju thoni “”Unë dua disa para.”” Ajo e pyet se ku paratë duhet të merret nga. Ju them se për të marrë atë nga llogaria juaj rrjedhëse. Ajo e pyet se sa. Ju thoni $ 100,00. Pastaj magjike ndodh â € | kjo ju jep $ 100,00. Pastaj ai pyet nëse doni një tjetër transaksion. Ju thoni nuk ka. Kjo ju jep kartën tuaj mbrapa, ju jep një faturë, dhe transaksioni është e gjatë. Ky është skenari i lumtur ditë.
Skenari i dytë. Ju shkoni deri në ATM, të futur kartën tuaj, dhe shkruani PIN-in tuaj. ATM ju tregon se është PIN gabim. Ju shkruani numrin tuaj përsëri. Përsëri ju jeni i tha se PIN është i pasaktë. Ju Në shembullin tim e regjistrimit të kursit, për shembull, ju mund të shihni se ka shumë “”nëse X pastaj Y”” menu. Kjo është ajo ku ju doni klientit tuaj për t’ju ndihmuar jashtë. Getting marrëveshje të hershme do të thotë që klienti juaj i kupton këto skenare dhe thotë “”po, kjo është ajo që ne duam.”” Përdorimi raste janë një mënyrë e madhe për të siguruar se ajo që ju jeni ndërtimin është me të vërtetë se çfarë dëshiron konsumatori, sepse ato tregojnë aktorët, e raste të përdorimit, dhe marrëdhëniet ndërmjet tyre.
Figura 5: Përdorimi rast diagramin
Pra, ne kemi një diagram të madhe që grafikisht tregon mua se çfarë? Përgjigjja është e thjeshtë â € “”kjo është një diagram i madh që tregon një pasqyrë të mirë të sistemit. Kjo tregon se ajo që është jashtë sistemit (aktorët) dhe funksionalitetin që sistemi duhet të sigurojë (raste të përdorimit). Nëse ka një sistem trashëgimi që ju duhet të marrë në konsideratë, këtu është ku të merren me të. Duke e detyruar mua për të punuar me këto lloje të ndërfaqeve shumë herët në këtë projekt do të thotë se unë nuk do të përballen me perspektivën e pritur deri coding fillon të kuptoj se si unë jam duke shkuar për të biseduar me atë kuti e zezë që unë nuk mund të ndryshojë .
Një gjë më shumë që ju duhet të dini në lidhje me raste të përdorimit është realizimi përdorimi rasti. Kjo është “”se si”” i përdorimit të rastit. Kjo është zakonisht një kovë që përmban tre lloje të ndryshme të diagramet: diagramet rend, diagramet bashkëpunimi, si dhe një diagram klasë që ne e quajmë një pamje të klasave pjesëmarrëse. Përdorimi realizimet e rasteve janë në thelb një mënyrë për të grupuar së bashku një numër të objekteve në lidhje me hartimin e një rast të përdorimit.
rend Diagramet
diagramet rend të treguar ndërveprime objekt të rregulluar në një rend kohor. Unë mund të përdorin rrjedhën e ngjarjeve për të përcaktuar se çfarë objekte dhe ndërveprimet unë do të duhet për të kryer funksionet e përcaktuar nga rrjedha e ngjarjeve.
Figura 6: Sequence diagram
Figura 6 tregon se si një student me sukses merr shtuar në një kurs. Studenti (le të thërrasë atë Joe) plotëson disa informacione dhe dorëzon formularin. Forma e pastaj flet për menaxherin dhe thotë: “”shtoni Joe të Math 101.”” Menaxheri i thotë Math 101 se ai ka për të shtuar një student. Math 101 thotë se me nenin 1 “”janë të hapur?”” Në këtë rast, Seksioni 1 përgjigje se ata janë të hapur, kështu që Math 101 tregon seksionin 1 për të shtuar këtë nxënës. Përsëri, diagramet rend janë mjete të mëdha në fillim, sepse ata ju dhe klientit tuaj tregojnë hap pas hapi se çfarë duhet të ndodhë.
Nga një pikë analizë të parë, unë kam gjetur gjatë viteve që diagramet rend janë shumë të fuqishme për të ndihmuar me makinë kërkesat; veçanërisht kërkesat që janë të vështirë për të gjetur. Kërkesat user interface, për shembull, janë të njohur për shkak se ju gjithmonë duket për të marrë kërkesat që nuk janë vetëm të testueshme. Një kërkesë e përbashkët UI si kjo është “”ky sistem do të jenë përdorues-miqësor.”” Sa prej jush kanë takuar një kompjuter miqësore? Një nga përfitimet e këtyre llojeve të diagrame është se çdo linjë që vjen nga një aktor që përfaqëson një person, ju tregon se diçka në UI tuaj ka për të siguruar një aftësinë e nevojshëm nga ai person. Me fjalë të tjera, ju mund të përdorni diagramet rend për të përzënë kërkesat testable user interface.
diagramet rend janë, pra, të mirë për të treguar se çfarë po ndodh, për ngarje kërkesat, dhe për të punuar me klientët. Kjo zakonisht çon në pyetjen, pse, se sa ju duhet për të krijuar? Përgjigja ime është, “”derisa ju të bëni të mjaftueshme.”” Ju jeni duke shkuar për të gjetur se kur ju bëni diagramet rend që të arrijnë një pikë ku ju nuk jeni të gjetur ndonjë objekte të reja, duke mos gjetur asnjë mesazhe të reja, dhe se ju jeni të shtypni të njëjtën gjë mbi dhe mbi. Në shembullin e Joe bashkimit Math 101, ne mësojmë se procesi do të jetë e njëjtë, nëse Joe dëshiron të bashkohet Historia 101. Pra, sundimin e gishtit, të bëjë një diagram rend për çdo rrjedhë themelore të çdo rast të përdorimit. Të bëjë një diagram rend për të nivelit të lartë, skenarët e rrezikshme, dhe kjo duhet të jetë e mjaftueshme. Kjo është sa diagramet rend të bëj.
për të kujtuar këtu është se një diagram bashkëpunim është vetëm një pikëpamje të ndryshme të një skenari dhe ju mund të shkoni mbrapa dhe me radhë në mes të diagramet rend dhe diagramet bashkëpunimit për të marrë mendimin që ilustron më mirë pika juaj.
Herë pas here, ju mund të dëgjoni shprehjen “”diagramet e ndërveprimit.”” Ndonjëherë njerëzit kolektivisht do t’i referohet një diagram bashkëpunimi dhe një diagram rend si një diagram ndërveprimit.
Class Diagramet
Një klasë është një koleksion i objekteve me strukturë të përbashkët, sjellje të përbashkët, marrëdhëniet e përbashkëta, dhe semantikë të përbashkëta. Që t’i gjeni duke shqyrtuar objektet në rend dhe bashkëpunimit diagramet, dhe ata janë të përfaqësuara në UML si një drejtkëndësh me tre compartments.
Figura 8: Klasat
Ndarje e parë tregon emrin e klasës, e dyta tregon strukturën e saj (atributet), dhe e treta tregon sjelljen e saj (operacionet). Këto compartments mund të jetë shtypur, megjithatë, në mënyrë që ju mund të shihni vetëm emrin, vetëm emrin dhe atributet, ose të gjitha tre. Një gjë që ju duhet të dini është se është e rëndësishme, kur emërtimin klasa, për të përdorur fjalorin e fushës dhe të zgjedhë një standard. Për këtë shembull, klasa e mi janë të gjithë emra njëjës që fillojnë me shkronjë të madhe. Ju mund të zgjidhni për të bërë atë ndryshe, dhe kjo nuk ka rëndësi. Çfarë ka rëndësi është se përpara projektin tuaj ju të vini një standard dhe rrinë me të në mënyrë që çdo gjë është në përputhje të gjithë projektin.
Class Diagramet ju tregojnë natyrën statike e sistemit tuaj. Këto diagrame tregojnë ekzistencën e klasave dhe marrëdhëniet e tyre në pikëpamje logjike e një sistemi. Ju do të keni shumë diagramet klasës në një model.
Elementet UML modelimit gjenden në diagramet klasës përfshijnë:
Klasat dhe strukturën dhe sjelljen e tyre.
Marrëdhëniet Association, agregim, varësisë, dhe të trashëgimisë.
treguesit shumëllojshmëria dhe lundrimit
emrat e roleve.
Hidhni një sy në figurën 9. Ky diagram tregon operacionet (sjelljen): çka një objekt në atë klasë mund të bëjë. Gjej operacionet tim duke shikuar në ndërveprimet diagramet e mia.
Figura 9: Operacionet
Këtu unë jam duke thënë se unë duhet të jetë në gjendje për të kërkuar menaxherin e regjistrimit për të shtuar një student për të Math
101. Kjo do të përkthehet në një operacion të quajtur “”addCourse.””
Struktura e një klasë përfaqësohet nga atributet saj. Pra, si mund ta gjej atributet e mia? Duke biseduar me ekspertët e fushës. Duke shikuar në kërkesat e mia. Në shembullin tim, kam mësuar se çdo flijim Sigurisht ka një numër, një vend dhe një kohë. Kjo përkthehet jashtë për tre atributeve.
klasa. (Përfaqësuar në UML si një vijë që lidh klasat lidhura me një diamant tjetër të klasës që përfaqëson të gjithë.)
â € ¢ Varësia â € “”një formë të dobët tregon marrëdhënien ndërmjet një klienti dhe një furnizues ku klienti nuk ka njohuri semantik të furnizuesit. Një varësisë thotë: “”Kam nevojë për shërbimet tuaja, por unë nuk e di se ti ekziston.”” (Përfaqësuar në UML si një linjë thye treguar nga klienti të furnizuesit.)
Për të gjetur marrëdhënie, edhe një herë, unë të kthehem në diagramin tim rend. Nëse dy objekte nevojë për të “”flasin””, nuk duhet të jetë një mjet për të bërë kështu (dmth, një marrëdhënie në mes të klasave të tyre).
Unë zakonisht fillojnë dhe të bëjë çdo gjë që një shoqatë. Si unë jam duke bërë shumë analiza, ta gjeja unë kam një grumbull, sepse unë do të duhet të kujdeset për një marrëdhënie prind-fëmijë. Kur unë të marrë në fazën e projektimit, kam gjetur se unë nuk mund të kenë nevojë një shoqatë për shkak se dikush tjetër do të kalojë atë objekt në një nga metodat e mia â € “”kështu që unë e bëjnë atë një varësisë.
Figura 11: Relationships
Në Figurën 11 po i shikon këto marrëdhënie. Si shoqatë thotë profesori mund të bisedoni me Ofrimi kursit, me ofertën e kursit mund të bisedoni me Profesor. Mesazhet mund të iniciohet dhe të dhënat mund të rrjedhin nga çdo drejtim. Grumbullimi është treguar duke pasur diamant drejt të gjithë â € “”në këtë rast një Course është e përbërë nga Ofertave kursit. Arsyeja për këtë bashkimi do të ishte për të të treguar zhvilluesit e mia se në qoftë se ata të hequr qafe këtë kurs, ata ndoshta do të duhet të bëjë diçka të veçantë me Ofertat kursit. Dependencies janë treguar si një linjë thye. Është thënë se menaxheri regjistrimi varet nga Listën Algoritmi për të bërë diçka. Orari Algoritmi është ose një parametër të një prej metodave apo deklarohet në nivel lokal nga një prej Metodat e menaxherit Regjistrimit.
Shumëllojshmëria dhe Navigation
Shumëllojshmëri përcakton se si shumë objekte të marrë pjesë në një marrëdhënie. Ajo është numri i rasteve të një klasë në lidhje me një rast të klasës tjetër. Për çdo shoqatë dhe grumbullimi, ka dy vendime shumëllojshmëri të bëjnë: një për çdo fund të marrëdhënies. Shumëllojshmëri përfaqësohet si një numër dhe a * është përdorur për të përfaqësojnë një shumëllojshmëri e shumë.
Figura 12: Shumëllojshmëri dhe navigacion
Një Profesor Objekti lidhet me zero-për-katër objekte Ofrimi Course. Një Course Ofrimi Objekti është i lidhur pikërisht një profesor Object. I përdorni këtë për të parë dhe për të siguruar që ky merret me kërkesat e mia. A mund të jetë një ofertë e kursit dhe të ekipit, mësohet nga një bandë e profesorëve? Jo, sepse kjo thotë se unë mund të ketë vetëm një profesor. A mund të jetë një profesor dhe të jetë në dielave? Po, sepse ky thotë se unë kam një zero si ngarkesë të mundshme të kursit. I përdorin shumëllojshmëri mjaft shpesh për të më ndihmuar të filluar kapjen dhe zbatimin e rregullave të mia të biznesit. Nëse keni, për shembull, një rregull biznesi që thotë se ju duhet të keni të paktën 3 studentë dhe jo më shumë se 10 për një kurs që do të ofrohet në një semestër, këto shifra shumësia më thoni që unë kam inkorporuar që sundimin e biznesit në këtë plan.
Navigation tregohet nga një shigjetë, dhe edhe pse shoqatat dhe bashkimet janë bi-drejtuar nga default, ajo shpesh është e dëshirueshme për të kufizuar navigacion në një drejtim. Kur navigacion është e kufizuar, një Arrowhead është shtuar për të treguar drejtimin e lundrimit. Një nga gjërat që kam bërë gjatë analizës dhe të projektimit faza është të shikojmë se çfarë unë dua të jem uni-drejtuar. Duke vënë arrow në këtë diagram, unë them se Menaxheri Regjistrimi mund të dërgoni një mesazh në Kursin, sepse ajo e di se ekziston Course. Por Kursi ka asnjë ide që ekziston Menaxheri i Regjistrimit, kështu që natyrisht nuk mund të iniciojë një mesazh. Tani të dhënat mund të rrjedhin mes tyre; për shembull Menaxheri i regjistrimit mund të kërkojë Kursin nëse është e hapur dhe e kursit mund të themi se ajo është. Por vetëm Menaxheri i regjistrimit mund të filloni atë bisedë.
Natyrisht qëllimi këtu është që të ketë sa më shumë shigjeta si ju mund nga koha që ju keni përfunduar projektim, sepse kjo është një sistem shumë më të lehtë për të ruajtur trashëgiminë është treguar me një trekëndësh. Kjo tregon se profesori është një User Regjistrimi, siç është Student. Tani, një fjalë e paralajmëruar. Trashëgimia është e dobishme, megjithatë, qëllimi nuk është që të përdorin sa më shumë trashëgiminë që sistemi juaj do të lejojë. Unë kam parë disa sisteme të vërtetë brutale, ku ata e patën trashëgiminë e 17-nivele të thellë. Nëse ata ndryshuar një gjë, ajo u bë një fatkeqësi. Pra, sundimi i gishtit është që të përdorin trashëgiminë vetëm kur ju me të vërtetë kanë një situatë trashëgimi.
Shtetërore tranzicionit Diagramet
Një diagram tranzicionit shtet tregon historinë e jetës së një klase të caktuar. Ajo tregon ngjarjet që shkaktojnë një tranzicion nga një shtet në tjetrin, dhe veprimet që rrjedhin nga një ndryshim i shtetit.
Figura 14: State tranzicioni diagram
I përdorur diagramet tranzicion shtetërore për klasat e objekteve që zakonisht kanë shumë të sjelljes dinamike. Butoni është në â € | butonin është jashtë; Unë nuk jam duke shkuar për të bërë një tabelë të shtetit për të. Por klasa objekt që kanë një shumë e sjelljes dinamike, unë jam ndoshta do të duhet të shikojmë në shtetet e objekteve.
Unë të fillojë duke treguar një shtet, i cili është një trekëndësh harmonishëm. Unë mund të ketë shtete fillimit, dhe unë mund të ketë shtete të ndaluar, të cilat janë treguar si demat e vegjël syve. Unë gjithashtu mund të tranzicionit në mes shteteve, apo tranzicionit roje (gjërat që ndodhin kur vetëm kur një kusht është i vërtetë), apo gjëra që ndodhin kur jam brenda shtetit. Unë shoh në këtë diagram dhe të shohin tranzicionit diagramin e shtetit si flijim për kurs. Ajo fillon në shtetin initialization, dhe unë të qëndrojnë në këtë gjendje deri sa unë të marrë një “”të shtoni nxënës”” mesazh. Kur kam marrë këtë mesazh, kam vendosur numërimin tim të studentit në zero dhe kalimin në gjendjen e hapur. Ju do të shihni në figurën 14 se kam një hyrje, dhe arsyeja pse është e nuk është se unë kam dy mënyra për të hyrë në atë shtet. Ai thotë se pa marrë parasysh se si ju vijnë në shtetin, unë dua që ju të regjistroheni studenti. Kur kam dalë atë shtet, ndryshimet e numërimit të mbajnë gjurmët e numrit të studentëve të kursit. Unë mund të mbani duke shtuar nxënësit deri sa të shkoj në 10, dhe pastaj do të shkoj tek Close shtetit. Pasi kurs është finalizuar, I kalojnë në shtetin ndaluar. Nuk ka rëndësi se ku jam unë, atëherë, në qoftë se unë të marrë Anuloje tranzicion Event, I njoftojë nxënësit e mi dhe pastaj të kalojnë në gjendjen e ndaluar.
Për klasat e objekteve që kanë një shumë e sjelljes dinamike, është e vlefshme edhe për të bërë një diagram të shtetit për të marrë një trajtuar në çdo gjë që ka për të ndodhë. Pyesni veten se çfarë ndodh kur kam marrë një mesazh? Çfarë të bëj kur kam marrë mesazh? Çfarë mesazhe të unë kam për të dërguar? Një shumë prej këtyre mesazheve bëhen operacionet e klasës objektit, si në këtë shembull, ku shtoni një student është një operacion. Një shumë prej këtyre veprimeve, si vendosjen numërimin, bën rritjen numërimin, duke kontrolluar numërimin, të gjitha këto bëhen operacionet private të asaj klase të veçantë objekt dhe një diagram shteti është kur unë shoh atë.
Si mund të dini nëse keni një klasë dinamike objekt? Edhe një herë, të shkojnë prapa në diagramet rend. Nëse ju keni një klasë objekt që është në një shumë të diagramet rend dhe po bëhet dhe të dërguar shumë mesazhe, kjo është një tregues i mirë se kjo është një klasë mjaft dinamike objekt dhe kjo ndoshta duhet të ketë një tabelë të shtetit për të. Gjithashtu për agregime, ku ju keni të gjithë të pjesëve të saj, të bëj një tabelë shtetërore për çdo tërësi agregate. Unë e bëj këtë kryesisht për shkak se tërë agregat shpesh është përgjegjës për menaxhimin e mesazheve, që e bën atë dinamike.
diagramet Komponenti
Sigurisht asnjë sistem mund të ndërtohet pa marrë parasysh botën fizike. Kjo është ku diagramet përbërëse të vijë në. Ata janë përdorur për të ilustruar organizatat dhe varësitë mes komponentët software, duke përfshirë komponentët burim të kodit, komponentëve në kohë të kandidojë, ose një komponent të ekzekutueshme. Përbërësit janë shfaqje si një drejtkëndësh të madhe me dy rectangles vogla në anën e, siç shihet në figurën 15.
Figura 15: Komponentet
Këto gjëra të rrumbullakëta përfaqësojnë ndërfaqe (shpesh quhet lollipop simbol). Në këtë rast, ata tregojnë se Register.exe varet ndërfaqeve të dy Course.dll dhe People.dll. Kjo do të thotë nëse këto ndërfaqe të ndryshojë, ajo do të ndikojë në Register.exe. Unë e di se nuk ka ky rregull kur ju jeni ndërtimin ndërfaqe që thotë se “”ti nuk do të ndryshojë interface.”” Por dikush të vërtetë punojnë, ku kjo rregull zbatohet? Ky diagram na tregon se çfarë Interfaces janë përdorur nga ajo që ekzekutuesit të vrapojnë në procesorë mia.
Figure 16: Diagrami vendosjen
Zgjerimi UML
Gjëja e fundit që dua të theksoj në lidhje me UML është se ajo mund të zgjatet. Kur ata ndërtuan UML, ata shumë mbarë çdo gjë e kuptuan se nuk kishte asnjë mënyrë ata mund të krijojnë një simbol që mund të ju lutemi të gjithë njerëzit të gjithë kohës. Pra, ata na dha konceptin e një stereotipi. Një stereotip thotë se unë mund të marrë një element themelor të modelimit dhe t’i jepte më shumë kuptim. Stereotipet mund të përdoret për të klasifikuar dhe për të zgjeruar shoqata, marrëdhëniet trashëgimore, klasa, dhe komponentet.
Figura 17: Web stereotip Shembulli
Figura 17 tregon diagramin e Web stereotipeve tona. Një faqe Web zakonisht ka sende që shkon në server dhe sende që shkon në të klientit. Nëse ju jeni ndërtimin e aplikacioneve Web-bazuar, se çfarë po kandidon për të klientit dhe serverit është e një rëndësie jetike. Pra, ne kemi një grup të tërë të stereotipeve që tregojnë se. Rrotat e vogla përfaqësojnë gjëra që të kandidojë në server. Pra, vetëm duke kërkuar në këtë një diagram unë mund të shoh se çfarë shkon në server, ajo shkon në të klientit, dhe çfarë objekte biznesi që duhet të merren me.

“——————————————————————————————————————————————————

ድጋፍ ትርጉም: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”ዘ UML, በመጥቀስ በዓይነ, ግንባታ, እና ሶፍትዌር ሥርዓት ሁሉ ቅርሶች መመዝገብ መደበኛ ቋንቋ ነው.””
የእንቅስቃሴ ሥዕላዊ
ወደ UML ንድፎችን አንዳንድ በኩል ጉዞ ለመጀመር ምክንያታዊ ቦታ እንቅስቃሴ ንድፎችን በመመልከት ነው.
ስእል 2; እንቅስቃሴ ንድፍ
እንቅስቃሴ ንድፎችን ቁጥጥር ፍሰት ያሳያሉ. በስእል 2 እንደሚታየው እናንተ የተጠጋጋ አራት መአዘን እንደ የሚወከለው እንቅስቃሴዎች ማየት ይችላሉ. € “”እርምጃ በኋላ ቀጣዩ ሁኔታ በራስ-ሰር ሽግግር ሙሉ በሙሉ እንደሆነ ይናገራል â እንቅስቃሴዎች በተለምዶ እርምጃ እንዲህ ይላል ናቸው. ክበብ ውስጥ ተሞልቶ ወደ â የእንቅስቃሴ ሥዕላዊ መጀመሪያ ይወክላል € “”የት ቁጥጥር ይጀምራል ፍሰት. እናንተ እንቅስቃሴ እንቅስቃሴ ለመሄድ እንዴት ቀስቶች ሆነው የሚታዩት ሽግግሮች ያሳያሉ. እንቅስቃሴዎች ትይዩ ውስጥ ሊከሰት እንዴት ማመሳሰል አሞሌዎች ያሳያሉ. እኔ “”እኔ ይህን ሁኔታ እውነት ከሆነ ብቻ ነው ይህን እንቅስቃሴ መሄድ እፈልጋለሁ”” ይላል አንድ ሽግግር መጠበቅ የምንችለው እና የት እንደጨረሰ እና እኔ ማሳየት እንችላለን. አንድ የተወሰነ ዕድሜ ከሆንክ አሁን, ምናልባት ይህን እንቅስቃሴ ዲያግራም ላይ እንመለከታለን እና አስብ “”€ â እምም |. አንድ ፍሰት ገበታ ይመስላል”” እና እኔም የፕሮግራም ደረጃ ላይ ታች መሥራት አልችልም በስተቀር, ምን እንደሆነ በትክክል ነው. በተለምዶ, እኔ የንግድ የስራ ፍሰት ማሳየት የእኔን ትንታኔ እና ዲዛይን ሂደት ላይ በአግባቡ መጀመሪያ ላይ እንቅስቃሴ ንድፍ ይጠቀሙ. እኔ ደግሞ አጠቃቀም ጉዳዮች እያንዳንዱ እንዲከሰት ምን አጠቃቀም ጉዳይ በምሳሌ ለማስረዳት አንድ እንቅስቃሴ ውስጥ ሊሆን ይችላል የት ለማሳየት እነሱን መጠቀም ይኖርብዎታል. እኔ ደግሞ ነገሮች የእኔ አጠቃቀም ጉዳዮች መካከል የሚፈሱባቸውን እንዴት እንደሆነ ለማሳየት እንቅስቃሴ ንድፎችን እንጠቀማለን.
ነገር ግን UML ስለ ታላላቅ ነገሮች መካከል አንዱ በውስጡ ያለውን ፈርጀ ብዙ ነው. እኔ ያሳድጓቸው መጀመሪያ ላይ እንቅስቃሴ ንድፎችን መጠቀም ሳለ ስለዚህ, ሌሎች ደግሞ ሙሉ በሙሉ የተለየ ምዕራፍ ውስጥ መጠቀም ይችላሉ. ሰዎች እንቅስቃሴ አንድ የተወሰነ ክፍል ስልተ በጣም የተወሳሰበ ስብስብ በሌለበት ንድፍ ደረጃ ላይ ወደ ታች ንድፎችን መጠቀም አይተናል. ብዙ ሰዎች አንድ ክፍል ዘዴዎች መካከል ያለውን ፍሰት ለማሳየት ይጠቀሙባቸው.
ስርዓቱ. ተዋንያን ዱላ አኃዝ ተደርገው ተገልጸዋል.
ስእል 4; ተዋናዮች
እኔ UML ይህን መግቢያ እስከ ይሠራ ዘንድ ምሳሌ ጎዳና የምዝገባ ሥርዓት ጥቂት ሞዴል ነው. የእኔ ትንተና ሂደት, መጠየቅ ነው ጀምሮ ወቅት በዚህ ለምሳሌ ውስጥ በመሆኑም, የመጀመሪያው ነገር እኔ ማድረግ ነበር “”በዚህ ሥርዓት ጋር መስተጋብር የሚሄድ ነው?””
ኮርስ ምዝገባ ሞዴል ያህል, አንድ የመዝገብ, ፕሮፌሰር, እና አንድ ተማሪ አላቸው. እኔ ደግሞ ውጫዊ የክፍያ ስርዓት አላቸው. ይህ የክፍያ ሥርዓት ደግሞ አንድ ተዋናይ ለመሆን ብቃቱን. (ተዋናይ ሥርዓት ጋር የሚገናኝ ነገር ግን ሥርዓት ውጭ ነው € “”ምንም ነገር ነው አንድ ሰው አንድ መሆን አይደለም, ን ተመልከት.)
አንድ አጠቃቀም ጉዳይ መገናኛ ውስጥ ሥርዓት ውስጥ ተዋናይ የፈጸማቸውን ተዛማጅ ግብይቶች ቅደም ተከተል ነው. ወይም ደግሞ, እንግሊዝኛ ውስጥ ለማስቀመጥ, አንድ አጠቃቀም ጉዳይ ተግባራዊነት ጸጉርም ነው. እዚህ ቁልፍ ነው: አንድ የሶፍትዌር ሞጁል â አይደለም € “”ይህ ተዋናይ ዋጋ የሚሰጥ ነገር ነው.
የአጠቃቀም ሁኔታዎች ovals ሆነው ነው የሚታዩት, እና እነሱን ለማግኘት ቀላሉ መንገድ ተዋናዮች እያንዳንዱ እንመለከታለን; እነሱም ስርዓት መጠቀም ይፈልጋሉ ለምን ራስህን መጠየቅ ነው. በእኔ ሁኔታ, የእኔ ሬጅስትራር የእኔ ተማሪ ፕሮግራም አጽንቷል, የእኔ ፕሮፌሰር የሆነ የስም መጠየቅ በመሄድ ላይ ነው, ሥርዓተ ይዘን በመሄድ ላይ ነው, እና የእኔ አከፋፈል ስርዓት አከፋፈል መረጃ ይቀበላል. ስለዚህ እኔ አመለካከት ደንበኛው ነጥብ ሆነው ሲመለከቱ እና በመጠየቅ የእኔ የአጠቃቀም ሁኔታዎች ለመፍጠር “”ስለዚህ, ወይዘሪት ስርዓት ተዋናይ, ለምን ስርዓቱ መጠቀም ይፈልጋሉ? ምን ዋጋ በዚህ ስርዓት እርስዎ የሚያቀርቡት እንዴት ነው?””
የእርስዎ ተዋናዮች ሥርዓት ጋር መስተጋብር ይሆናል እንዴት ተለይተው አንዴ ወደ ቀጣዩ እርምጃ, የእርስዎ አጠቃቀም ጉዳዮች ሰነድ አድርጉት ነው. እያንዳንዱ አጠቃቀም ሁኔታ ክስተቶች ፍሰት ጋር መመዝገብ አለበት, እና በዚህ አመለካከት ላይ ተዋናይ አንጻር ነው የሚደረገው. አጠቃቀም ጉዳይ የሚያስፈጽምበትን ጊዜ በዝርዝር ስርዓቱ ተዋንያን ጋር ማቅረብ ይኖርበታል እንዳለበት. በዋናነት ይህ አጠቃቀም ጉዳይ ይጀምራል እንዲሁም የማጠናቀቂያ እንዴት ያሉ ነገር አሳይሃለሁ አለ. ምን ዓይነት ነገሮች መጠቀም ጉዳይ ምን የሚያገናኘው ነገር ይኖራል? እናንተ ሁሉም ነገር እንደሚሰራ ቦታ (እኔ “”ደስተኛ ዘመን”” ሁኔታ የምንጠራው) ክስተቶች መደበኛ ፍሰት, ይኖርዎታል. በዚያን ጊዜ እናንተ ክስተቶች ላይ ያልተለመደ ፍሰት, የ “”ዝናባማ ቀን”” ሁኔታ ያገኛሉ. ስርዓቱ አይሰራም ጊዜ ምን ይሆናል? እኔ ሁልጊዜ ደስተኛ ቀናት ሁኔታ ጋር መጀመር የሚችሉ በርካታ ክስተቶችን የእኔ ፍሰት መመዝገብ በማድረግ አግኝተንበታል.
-ሰር Teller Machine እስከ እየሄዱ, አንድ እንደ ምሳሌ እንውሰድ. የ ATM ድረስ መሄድ እና በእርስዎ ካርድ ያስገቡ. የእርስዎ ፒን ቁጥር ይጠይቃል. አንተ ያስገቡ, እና ማድረግ የምትፈልገውን ነገር ይጠየቃሉ. እናንተ “”እኔ ጥቂት ገንዘብ እፈልጋለሁ.”” ይላሉ ይህ ገንዘብ ከ መወሰድ እንዳለባቸው ይጠይቃል. የ የቼኪንግ አካውንት ከ መውሰድ ንገራት. ይህ ምን ያህል ይጠይቃል. አንተ $ 100.00 ይላሉ. እናንተ $ 100.00 ይሰጣል | € â ከዚያም ድግምት ይከሰታል. ሌላ ግብይት ከፈለጉ ከዚያም ይጠይቃል. ምንም ይላሉ. ይህ መልሰው የእርስዎ ካርድ ይሰጥዎታል ደረሰኝ ይሰጣል, እና ግብይት ላይ ነው. ይህ አስደሳች ቀን ሁኔታ ነው.
በሁለተኛው ምሳሌ. የ ATM ውጡ: ካርድዎን ያስገቡ, እና የእርስዎን ፒን ያስገቡ. የ ATM ይህ የተሳሳተ ፒን ነው ይነግርዎታል. እንደገና ወደ ቁጥር ያስገቡ. እንደገና ላንተ ፒን ትክክል እንደሆነ ተነግሯቸዋል. አንተ ጎዳና ምዝገባ ምሳሌ ላይ, ለምሳሌ ያህል, «X ከሆነ ከዚያ Y» ደንቦችዎን ብዙ እንዳሉ ማየት ይችላሉ. እናንተን ለማገዝ ደንበኛ የፈለጉትን ቦታ ይህ ነው. ማግኘት ስምምነት ቀደም ብሎ ደንበኛ በእነዚህ ሁኔታዎች ይረዳል እንዲህ ማለት ነው “”አዎ, ይህ እኛ የምንፈልገውን ነገር ነው.”” እነርሱ ተዋናዮች, አጠቃቀም ጉዳዮች, እና በእነርሱ መካከል ያለውን ግንኙነት ለማሳየት ምክንያቱም የአጠቃቀም ሁኔታዎች, ምን እየገነባን ነው ደንበኛው የሚፈልገው ነገር በእርግጥ መሆኑን ለማረጋገጥ ታላቅ መንገድ ናቸው.
ስእል 5; ሁኔታ ንድፍ ይጠቀሙ
ስለዚህ እኛ በግራፊክ ለእኔ ምን የሚያሳይ ታላቅ ንድፍ አላቸው? መልሱ ይህ ሥርዓት ጥሩ አጠቃላይ የሚያሳይ ታላቅ ንድፍ ነው “”ቀላል â ነው €. ይህ ሥርዓት (ተዋናዮች) እና ስርዓቱ (የአጠቃቀም ሁኔታዎች) ማቅረብ አለበት የሚል ተግባር ውጭ ነው; ምን ያሳያል. አንተ ከግምት መግባት አለብዎት የቆየ ሥርዓት ካለ እናንተ ለመቋቋም የት, እዚህ ላይ ነው. በይነገጾች በእነዚህ አይነቶች ጋር ለመሥራት እኔን ማስገደድ እጅግ ማልደው ፕሮጀክት ላይ እኔ እኔ መለወጥ አይችልም በጥቁር ሳጥን ጋር መነጋገር መሄዴ ነው የምትችለው እንዴት እንደሆነ ማወቅ ሲጀምር ኮድ ድረስ በመጠበቅ ተስፋ ሲያጋጥመው አይሆንም ማለት ነው .
አንተ አጠቃቀም ጉዳዮች ማወቅ ያለበት አንድ ተጨማሪ ነገር አጠቃቀም ጉዳይ መገንዘቤ ነው. ይህ የ “”እንዴት”” መጠቀም ጉዳይ ነው. ቅደም ተከተል ሥዕላዊ መግለጫዎች, ትብብር ሥዕላዊ መግለጫዎች, እና እኛም ተሳታፊ ክፍሎች አንድ አመለካከት ይጠሩታል አንድ ክፍል ንድፍ: ብዙውን ጊዜ ንድፎችን ሦስት የተለያዩ አይነቶች የያዘ አንድ ባልዲ ነው. የአጠቃቀም ሁኔታ እንድንገነዘብ በመሠረቱ አብረው አጠቃቀም ጉዳይ ንድፍ ጋር የተያያዙ ቅርሶች በርካታ የመልክ አንድ መንገድ ነው.
ቅደም ሥዕላዊ
ቅደም ተከተል ንድፎችን ጊዜ በቅደም ተከተል ዝግጅት ነገር መስተጋብሮችን ያሳያል. እኔ ክስተቶች ፍሰት የተገለጸው ተግባር ለመፈጸም ያስፈልገናል ምን ነገሮችን እና መስተጋብር እኔ ለመወሰን ክስተቶች ፍሰት መጠቀም ይችላሉ.
ስእል 6; ተከታታይ ንድፍ
ስእል 6 ተማሪ በተሳካ ጎዳና ታክሏል አይቀርም እንዴት እንደሆነ ያሳያል. ተማሪው አንዳንድ መረጃዎች ውስጥ የሚሞላ እና ቅጽ ያቀርባሌ (የአምላክ ጆ ወደ እርሱ ይጥራ;). ቅጹ ከዚያም አስተዳዳሪ ጋር የሚነጋገር እና “”ሒሳብ 101. ወደ ጆ አክል”” ይላል ሥራ አስኪያጅ አንድ ተማሪ ለማከል ያለው ሒሳብ 101 ይናገራል. ሒሳብ 101 “”ለመክፈት ነህ?”” ክፍል 1 እንዲህ ይላል ሒሳብ 101 ይህ ተማሪ ለማከል ክፍል 1 ይነግረናል ስለዚህ በዚህ ሁኔታ, ክፍል 1 ምላሾችን እነርሱም ክፍት ናቸው. አንተ እና የእርስዎ የደንበኛ ደረጃ-በ-ደረጃ እንዲደርሱ ምን ያሳያሉ ምክንያቱም እንደገና, በቅደም ተከተል ንድፎችን ምርጥ መሣሪያዎች መጀመሪያ ላይ ናቸው.
አመለካከት ትንታኔ ነጥብ ጀምሮ እኔ በዚያ ቅደም ተከተል ንድፎችን እኔን መስፈርቶች መንዳት ለመርዳት በጣም ኃይለኛ ናቸው ዓመታት በላይ ማግኘታቸው; ማግኘት አስቸጋሪ ነው, በተለይም መስፈርቶች. ሁልጊዜ ብቻ መፈተሽ ያልሆኑ መስፈርቶች ለማግኘት ይመስላል ምክንያቱም የተጠቃሚ በይነገጽ መስፈርቶች, ለምሳሌ ያህል, በጭካኔያቸው የታወቁ ናቸው. ይህ እንደ አንድ የተለመደ በይነገጽ መስፈርት “”የዚህ ሥርዓት ተጠቃሚ ተስማሚ ይሆናል”” ነው. ስንት ከእናንተ ወዳጃዊ ኮምፒውተር ተገናኘን ነው? ንድፎችን የእነዚህ አይነት ጥቅሞች መካከል አንዱ አንድ ሰው የሚወክል ተዋናይ የሚመጣው ሁሉ መስመር, ያንን ሰው አስፈላጊ የሆነ ችሎታ ለመስጠት ያለው የ UI ውስጥ የሚነግረን ነገር ነው. በሌላ አነጋገር, መፈተሽ የተጠቃሚ በይነገጽ መስፈርቶች ውጭ ማሽከርከር ቅደም ንድፎችን መጠቀም ይችላሉ.
ቅደም ሥዕላዊ መግለጫዎች, ስለዚህ, መስፈርቶች ውጭ መንዳት, እና ደንበኞች ጋር ለመሥራት, ምን እየተካሄደ እንዳለ ለማሳየት ጥሩ ናቸው. ይህ ብዙውን ጊዜ መፍጠር ይኖርብሃል ምን ያህል ነው, ይሁን እንጂ ጥያቄ ይመራል? “”በቂ ማድረግ ድረስ.”” የእኔ መልስ ነው እርስዎ, ማንኛውም አዲስ ነገሮችን የማግኘት እንጂ ማንኛውም አዲስ መልዕክቶች እያገኘን አይደለም የት አንድ ነጥብ ላይ ለመድረስ ተከታታይ ንድፎችን ሲያደርጉ ለማወቅ ይሄዳሉ, እና ደጋግሞ ተመሳሳይ ነገር እየተየቡ ነው. ጆ ሒሳብ 101 መቀላቀል ምሳሌ ውስጥ, እኛ, ጆ ስለዚህ ታሪክ 101., ጣት አገዛዝ አባል መሆን ፈልጎ ከሆነ ሂደት ተመሳሳይ እንደሚሆን መማር ሁሉ አጠቃቀም ጉዳይ ሁሉ መሠረታዊ ፍሰት ቅደም ተከተል ንድፍ ነው. ከፍተኛ-ደረጃ, አደገኛ ሁኔታዎች አንድ ተከታታይ ንድፍ አድርግ, እና በቂ ሊሆን ይገባል. ይህ እኔ ማድረግ ምን ያህል ቅደም ተከተል ንድፎችን ነው.
እዚህ ላይ ማስታወስ, አንድ የትብብር ንድፍ አንድን ሁኔታ ብቻ የተለየ አመለካከት ነው እና ምርጥ ነጥብ የሚያሳይ አመለካከት ለማግኘት ቅደም ንድፎችን እና ትብብር ንድፎችን መካከል ወደ ኋላ ወደ ውጭ መሄድ የሚችል መሆኑ ነው.
አልፎ አልፎ, እናንተ የሚለው ሐረግ “”መስተጋብር ንድፎችን.”” መስማት ይችላል አንዳንድ ጊዜ ሰዎች በጋራ አንድ ትብብር ንድፍ እና ግንኙነቶች ዲያግራም እንደ ቅደም ተከተል ዲያግራም የሚያመለክት ነው.
የክፍል ሥዕላዊ
አንድ ክፍል የተለመደ መዋቅር, የጋራ ባህሪ, የጋራ ግንኙነት, እና የጋራ ስንጠቃ ጋር የነገሮች ስብስብ ነው. አንተ ቅደም ተከተል እና የትብብር ንድፎችን ውስጥ ነገሮች በመመርመር እነሱን ማግኘት, እና ሦስት ጉርጆችን ጋር አራት ማዕዘን እንደ UML ውስጥ ይወከላሉ.
ስእል 8; ክፍሎች
የመጀመሪያው ክፍል ሁለተኛው ያለውን መዋቅር (ባሕርያት) ያሳያል; በክፍል ስም ያሳያል, እና ሦስተኛው ባህርይ (ቀዶ) ያሳያል. አንተ ብቻ ስም ብቻ ስም እና ባህሪያት, ወይም ሁሉንም ሦስት ማየት እንችል ዘንድ እነዚህ ጉርጆችን, ይሁን እንጂ, የታፈኑ ይችላል. እናንተ ደግሞ ማወቅ አለባቸው አንድ ነገር ጎራ ቃላት መጠቀም እና አንድ መደበኛ መምረጥ, ክፍሎችን ላይ ከመዋላቸው ጊዜ, አስፈላጊ መሆኑ ነው. ይህ ለምሳሌ ያህል, የእኔ ትምህርት ካፒታል ደብዳቤ ጋር ይጀምራሉ ሁሉ ነጠላ ስሞች ናቸው. በተለየ ማድረግ መምረጥ ይችላሉ, እና ይህ ለውጥ አያመጣም. ምን ጉዳይ ነው የእርስዎን ፕሮጀክት በፊት መሥፈርት መምረጥ እና ሁሉም ነገር ፕሮጀክት በመላ ወጥነት ነው; ስለዚህ ከእርሱ ጋር መጣበቅ ነው.
ክፍል ሥዕላዊ የ ሥርዓት ቋሚ ተፈጥሮ ያሳያሉ. እነዚህ ሥዕላዊ ክፍሎች እና ሥርዓት ምክንያታዊ አመለካከት ውስጥ ያላቸውን ግንኙነት መኖሩን ያሳያሉ. አንድ ሞዴል ውስጥ ብዙ ክፍል ንድፎችን ይኖራቸዋል.
ክፍል ንድፎችን ውስጥ የሚገኘው UML ሞዴሊንግ ክፍሎች የሚከተሉትን ያካትታሉ:
ትምህርቶቹ እና መዋቅር እና ጠባይ.
ማህበር, አጠቃላይ ድምር, ጥገኝነት, እና ርስት ግንኙነት.
ባለብዙ እና የአሰሳ አመልካቾች
ሚና ስሞች.
ይህ ንድፍ ክወናዎች (ባህሪ) ያሳያል ስእል 9 ላይ ይመልከቱ: በዚያ ክፍል ውስጥ አንድ ነገር ማድረግ የሚችለው ነገር. እኔ ግንኙነቶች ንድፎችን በመመልከት የእኔን ክወናዎችን እናገኛለን.
ስእል 9; ክወናዎች
እነሆ, እኔ ሒሳብ, አንድ ተማሪ ለማከል ምዝገባ አስተዳዳሪ መጠየቅ መቻል አለብን ብሎ ነኝ
የተባለ ቀዶ ወደ ለመተርጎም እየሄደ ነው ይህ 101. “”addCourse.””
አንድ ክፍል አወቃቀር የባህርይ መገለጫዎች ነው የሚወከለው. ታዲያ እንዴት እኔ ባህሪያት ማግኘት እችላለሁ? ጎራ ባለሙያዎች ጋር መነጋገር ነው. የእኔ መስፈርቶች በመመልከት. የእኔ ምሳሌ ውስጥ, እያንዳንዱ ኮርስ መሥዋዕት አንድ ቁጥር, አንድ አካባቢ, እና አንድ ጊዜ እንዳለው እንማራለን. ይህም ሦስት ባሕርያት ወደ ውጭ የተተረጎመ ነው.
ክፍሎች. (ሙሉውን የሚወክሉ ለክፍሉ ቀጥሎ አልማዝ ጋር የተዛመዱ ክፍሎች ጋር በመስመር እንደ UML ይወከላሉ.)
€ ¢ ጥገኛና € â “”ደካማ ቅጽ አንድ ደንበኛ እና ደንበኛው አቅራቢው የፍቺ እውቀት የለውም ቦታ አቅራቢዎች መካከል ያለውን ግንኙነት የሚያሳይ. አንድ ጥገኝነት “”እኔ አገልግሎቶች ያስፈልጋቸዋል, ነገር ግን እኔ አንተ እንዳለህ አውቃለሁ አይደለም.”” ይላል (አቅራቢው ወደ ደንበኛ የሚያመላክቱ ገፋው መስመር እንደ UML ይወከላሉ.)
ግንኙነት ለማግኘት, እንደገና, እኔ ቅደም ተከተል ዲያግራም መመለስ. ሁለት ነገሮች “”መነጋገር”” ይኖርብናል ከሆነ, መንገድ ይህን ለማድረግ መኖር አለበት (ማለትም, ያላቸውን ክፍሎች መካከል ግንኙነት).
እኔ በተለምዶ ውጭ መጀመር እና ሁሉም ነገር አንድ ማህበር ማድረግ. ተጨማሪ ትንተና ድርጊቴ እንደ እኔ አንድ ወላጅ-የልጅ ግንኙነት እንክብካቤ መውሰድ አለባቸው መሄድ ነኝ ምክንያቱም እኔ ድምር አለኝ ማግኘት ይችላል. እኔ ንድፍ ዙር በመጣህ ጊዜ: እኔ ሌላ ሰው € የእኔ ዘዴዎች “”ስለዚህ አንድ ጥገኝነት ለማድረግ አንዱ ወደ በዚያ ነገር ያልፍ ዘንድ ነው; ምክንያቱም እኔ ማህበር አያስፈልገንም ዘንድ ለማግኘት.
ስእል 11; ግንኙነቶች
ስእል 11 ውስጥ እነዚህን ግንኙነቶች ማየት. ማህበር እንደ ፕሮፌሰር ወደ ፕሮፌሰር ማነጋገር ይችላሉ የቀየረ መስዋዕት, እና የቀየረ መባ ማነጋገር ይችላሉ ይላል. መልዕክቶች ማስጀመር ይቻላል እና ውሂብ ከማንኛውም አቅጣጫ ይፈልቃል ይችላሉ. አጠቃላይ ድምር አንድ ኮርስ የኮርስ መባዎች ያቀፈ ነው በዚህ ጉዳይ ላይ “”ሁሉ â € አቅጣጫ የአልማዝ ይዞ ይታያል. የዚህ ድምር ምክንያት በዚህ ኮርስ ማስወገድ ከሆነ, እነርሱ ምናልባትም ኮርስ መባዎች ጋር ለየት ያለ ነገር ማድረግ ይኖርብዎታል የእኔ ገንቢዎች መንገር ነበር. ጥገኝነቶች አንድ ገፋው መስመር ሆነው ነው የሚታዩት. ይህ ምዝገባ አስተዳዳሪ የሆነ ነገር ለማድረግ ፕሮግራም አልጎሪዝም ላይ የተመካ ነው እያሉ ነው. የ ፕሮግራም አልጎሪዝም ዘዴዎች መካከል አንዱ ላይ አንድ ልኬት ነው ወይም የምዝገባ አስኪያጅ ዘዴዎች መካከል አንዱ በአካባቢው ተናግሯል ነው.
ባለብዙ እና አሰሳ
ባለብዙ ብዙ ነገሮች ግንኙነት ውስጥ መሳተፍ እንዴት እንደሆነ ይገልፃል. ይህ ሌላ ክፍል አንድ ለምሳሌ ጋር የሚዛመዱ አንድ ክፍል አጋጣሚዎች ብዛት ነው. ግንኙነት ዳርና ዳር አንድ: እያንዳንዱ የመደራጀት እና ድምር ያህል, ለማድረግ ሁለት, ባለብዙ ውሳኔዎች አሉ. ባለብዙ እንደ ቁጥር ተወክሏል እና * ብዙ የሆነ, ባለብዙ ለማመልከት ተሠርቶበታል.
ስእል 12; ባለብዙ እና የማውጫ ቁልፎች
አንድ ፕሮፌሰር የነገር ዜሮ-ወደ-አራት ኮርስ መስዋዕት ነገሮች ጋር የተያያዘ ነው. የነገር ማቅረብ አንድ ኮርስ ልክ አንድ ፕሮፌሰር የነገር ጋር የተያያዘ ነው. እኔ በመመልከት ይህ ብቃቶች መያዣዎች መሆኑን ለማረጋገጥ ይህንን ይጠቀማሉ. እኔ ኮርስ መስዋዕት ሊሆኑ ይችላሉ, እና ፕሮፌሰሮች ዐበዛ በ ቡድን-መማር? አይ, ይህን አንድ ጊዜ ብቻ ፕሮፌሰር ሊኖረው ይችላል ስላለ ነው. እኔ ፕሮፌሰር መሆን እና የሰንበት ላይ ሊሆን ይችላል? እንዲህ ይላል ምክንያቱም አዎ, በተቻለ አካሄድ ጭነት እንደ ዜሮ አላቸው. እኔ እኔን እንዲያዝ እና የእኔ ንግድ ደንቦች ተግባራዊ ለማስጀመር የሚረዳ በጣም ብዙ ጊዜ, ባለብዙ ይጠቀማሉ. የምታውቅ ከሆነ, ለምሳሌ, ቢያንስ 3 ተማሪዎች እና አንድ ኮርስ ከእንግዲህ ወዲህ ከ 10 በአንድ ሴሚስተር ውስጥ መሥዋዕት ለመሆን ሊኖረው ይገባል ይላል አንድ የንግድ አገዛዝ, እነዚህ ብዙነትንና ቁጥሮች እኔ በዚህ ዕቅድ ውስጥ የንግድ አገዛዝ እንደሆነ የተካተቱ አግኝተናል እኔ እላችኋለሁ.
አሰሳ በቀስት ይታያል, እና ማኅበራት እና ውሑድ bi-አቅጣጫ በነባሪነት ናቸው ቢሆንም ብዙውን ጊዜ አንድ መመሪያ የማውጫ ለመገደብ አስፈላጊ ነው. የማውጫ ቁልፎች የተገደበ ነው ጊዜ, አንድ ሊያሸንፉት ወደ ላይ ጉዞ አቅጣጫ ያመለክታሉ ታክሏል ነው. ወደ ትንተና እና የንድፍ ደረጃዎች ወቅት እኔ ምን ነገሮች መካከል አንዱ እኔ uni-A ቅጣጫ ምን መሆን እንደሚፈልጉ, መመልከት ነው. ይህ ሥዕላዊ ወደ ቀስት በማስቀመጥ, እኔ ጎዳና አለ ስለሚያውቅ የምዝገባ ስራ አስኪያጅ, የቀየረ መልዕክት መላክ ይችላሉ ይላሉ. ነገር ግን ጎዳና የምዝገባ አስተዳዳሪ መኖሩን ምንም ሀሳብ የለውም, ስለዚህ ኮርስ መልዕክት ማስጀመር አይችሉም. አሁን ውሂብ በመካከላቸው የሚፈሱባቸው ይችላሉ; ለምሳሌ ያህል ክፍት ነው ከሆነ ምዝገባ አቀናባሪ የቀየረ መጠየቅ ይችላሉ እና የቀየረ ነው ማለት እንችላለን. ነገር ግን ብቻ የምዝገባ አስተዳዳሪ ይህን ውይይት መጀመር ይችላሉ.
ግልጽ እዚህ ግብ አንድ ማዕዘን ጋር ይታያል ውርስ መጠበቅ በጣም ቀላል ሥርዓት ነው; ምክንያቱም እናንተ ከጊዜው የተነሳ, ዲዛይን ሲጨርሱ ይችላሉ መጠን ብዙ ቀስቶችን ማግኘት ነው. ይህ ተማሪ ነው እንደ ፕሮፌሰር, የምዝገባ ተጠቃሚ እንደሆነ ያሳያል. አሁን, የማስጠንቀቂያ ቃል. ውርስ ይሁን እንጂ ግብ የእርስዎን ስርዓት አይፈቅድም ያህል ርስት መጠቀም ነው, ጠቃሚ ነው. እነርሱ ጥልቅ ርስት 17-ደረጃ በሌለበት አንዳንድ በጣም ጭካኔ ስርዓት አይተናል. እነዚህ አንድ ነገር ተለውጧል ከሆነ, ይህ አደጋ ሆነ. ስለዚህ ጣት አገዛዝ በእርግጥ ርስት ሁኔታ አለን ብቻ ርስት መጠቀም ነው.
መንግስት የሽግግር ሥዕላዊ
አንድ ግዛት የሽግግር ንድፍ በአንድ የተሰጠ ክፍል የሕይወት ታሪክ ያሳያል. በአንድ ሁኔታ ወደ ሌላው ሽግግር የሚያመጡ ክስተቶች, እና ሁኔታ ለውጥ ውጤት እንደሆነ እርምጃዎች ያሳያል.
ስእል 14: ስቴት የሽግግር ንድፍ
እኔ በተለምዶ ተለዋዋጭ ባሕርይ ብዙ እንዳላቸው ነገር ክፍሎች ግዛት ሽግግር ንድፎችን ይጠቀማሉ. አዝራሩን â € ላይ ነው | አዝራሩን ጠፍቷል ነው; እኔም በእርሱ ሁኔታ ገበታ ማድረግ አልችልም. ነገር ግን ተለዋዋጭ ባሕርይ ብዙ እንዳላቸው ነገር ክፍሎች, እኔ ምናልባትም የነገሮችን ግዛቶች ሊመለከተው ለማድረግ መሄዴ ነው.
እኔ የተጠጋጋ ማዕዘን የሆነ ግዛት, በማሳየት ይጀምራል. እኔ መጀመሪያ እንዲህ ይላል ሊኖረው ይችላል, እና እኔ በሬዎች ዓይን ይታያሉ ይህም ማቆሚያ እንዲህ ይላል: ሊኖረው ይችላል. እኔ ደግሞ እንዲህ ይላል: ወይም ጠባቂ ሽግግሮች (ሀ ሁኔታ እውነት ነው; ጊዜ ብቻ ሊከሰት ነገር), ወይም እኔ ግዛት ውስጥ ነኝ ጊዜ ሊከሰት ነገሮች መካከል ሽግግሮችን ይችላሉ. እኔ በዚህ ሥዕላዊ ተመልከት እና አንድ ኮርስ መሥዋዕት ግዛት የሽግግር ዲያግራም ተመልከት. ይህ ማስጀመር ሁኔታ ውስጥ ይጀምራል, እና እኔ “”ተማሪ አክል”” መልዕክት ማግኘት ድረስ በዚያ ሁኔታ ውስጥ ይቆያሉ. እኔ ይህን መልዕክት ማግኘት ጊዜ, እኔ ወደ ዜሮ ተማሪ የእኔ ብዛት ማዘጋጀት እና እኔ ክፈት ሁኔታ ለመሸጋገር. በስእል እኔ አንድ ግቤት ያላቸው 14 ላይ ያያሉ, እና በዚያ ነው የሆነበትን ምክንያት እኔ በዚያ ሁኔታ ውስጥ ማግኘት ሁለት መንገዶች ያላቸው መሆኑ ነው. ምንም ነገር ወደ ሁኔታ ወደ እንዴት እኔ ተማሪው ለመመዝገብ የሚፈልጉ እንደሆነ ይናገራል. እኔ ይህን ሁኔታ ለመውጣት ጊዜ, ብዛት ለውጥ ጎዳና ላይ ተማሪዎች ቁጥር መከታተል ነው. እኔ 10 ወደ ለማግኘት ድረስ ተማሪዎች ማከል መቀጠል ይችላሉ, ከዚያ እኔም ዝጋ ሁኔታ ይሂዱ. ሩጫውን መጠናቀቁን አንዴ, እኔ የማቆም ሁኔታ ለመሸጋገር. እኔ ይቅር ክስተት ሽግግር ማግኘት ከሆነ, እኔ ተማሪዎች ማሳወቅ ከዚያም የማቆም ሁኔታ ለመሸጋገር, ከዚያ ባለሁበት ምንም ይሁን.
ተለዋዋጭ ባሕርይ ብዙ ያላቸው ነገር ክፍሎች, ይህ እንዲደርስብን ያለው ሁሉ ላይ እጀታ ለማግኘት ሁኔታ ንድፍ ማድረግ የሚያስቆጭ ነው. እኔ አንድ መልዕክት ማግኘት ስንጨምር ምን ብለህ ራስህን ጠይቅ? እኔ መልዕክት ማግኘት ጊዜ ምን ማድረግ A ለብኝ? እኔ ምን መልዕክቶችን ለመላክ ነው? እነዚህ መልዕክቶች ብዙ አንድ ተማሪ ቀዶ ሕክምና የት ለማከል በዚህ ምሳሌ ውስጥ እንደ ዕቃ ክፍል ክወናዎችን ይሆናሉ. እነዚህን እርምጃዎች ብዙ ሆይ: ብዛት ቅንብሩን ብዛት incrementing ወደ ቆጠራ በመፈተሽ እንደ እነዚህ ሁሉ የተለየ ነገር ክፍል የግል ቀዶ እንዲሆኑ እኔ ማየት በሚችልበት ሁኔታ ንድፍ ነው.
አንድ ተለዋዋጭ ነገር ክፍል ካለዎት ማወቅ የምትችለው እንዴት ነው? አንድ ጊዜ እንደገና, ተከታታይነት ንድፎችን ይመለሱ. አንተ ቅደም ንድፎችን ብዙ ላይ ያለ ነገር ቡድን የላቸውም እና ማግኘት እና መልዕክቶች ብዙ መላክ ነው ከሆነ, ይህ አንድ በትክክል ተለዋዋጭ ነገር ክፍል ነው ጥሩ ፍንጭ ነው እና ምናልባት አንድ ግዛት ገበታ ሊኖራቸው ይገባል. ደግሞ ክፍሎች በሙሉ ባለባቸው ውሑድ: ስለ እኔ ሁሉ ድምር በሙሉ አንድ ግዛት ገበታ ነው. ውሁድ ሁሉ ተለዋዋጭ ያደርገዋል በመልዕክት, የማቀናበር ብዙውን ጊዜ ኃላፊነት ነው; ምክንያቱም በአብዛኛው ይህን ማድረግ.
ክፍለ አካል ንድፎችን
እርግጥ ነው ምንም የስርዓት መለያ ወደ አካላዊ ዓለም ይዞ ያለ መገንባት ይቻላል. ይህ ክፍል ንድፎችን ውስጥ በምኵራብና. እነርሱም ምንጭ ኮድ ክፍሎች, መሮጥ ጊዜ ክፍሎች, ወይም executable አካል ጨምሮ, የሶፍትዌር ክፍሎች መካከል ድርጅቶች እና ጥገኝነቶች ለማስረዳት ጥቅም ላይ ነው. ስእል 15 ላይ እንደተመለከትነው ያሉ ክፍሎችን, ከጎን ላይ ሁለት ትናንሽ ማዕዘናት ጋር ትልቅ ሬክታንግል እንደ ትዕይንቶች ናቸው.
ስእል 15; አካላት
እነዚህ ክብ ነገሮች በይነገጽ (ብዙ ጊዜ ሊሊፖፕ በመወሰኑ) ይወክላሉ. በዚህ ሁኔታ ውስጥ, ወደ Register.exe ወደ Course.dll እና People.dll ሁለቱም ወደ በይነገጽ ላይ የተመሠረተ መሆኑን ያሳያል. እነዚህ በይነ መቀየር ከሆነ, ይህ Register.exe ላይ ተጽዕኖ ይኖረዋል ማለት ነው. እኔ እንዲህ ይላል እናንተ በይነ እየገነባን ጊዜ ይህ ደንብ እንዳለ እናውቃለን “”አንተ በይነገጽ መቀየር አለበት.”” ይህ ደንብ ተፈጻሚ ነው የት ነገር ግን ማንም ሰው በእርግጥ መሥራት እንዴት ነው? ይህ ንድፍ ነገር ተፈፃሚዎች የእኔ በአቀነባባሪዎች ላይ በመስራት ላይ ናቸው ጥቅም ላይ ምን በይነ ይነግረናል.
ስእል 16; ማሰማራት ንድፍ
UML በማስቀጠል
እኔ UML ስለ ጠበቅ አድርጎ ይፈልጋሉ የመጨረሻ ነገር ግን ሊራዘም የሚችል መሆኑ ነው. እነርሱ UML ሠራ ሲሆኑ, በጣም በጥበብ እነርሱ ጊዜ ሁሉ ሕዝቡ ሁሉ ደስ የሚችል አንድ ምልክትን መፍጠር አልቻለም ምንም ዓይነት መንገድ የለም መሆኑን ተገንዝቦ ነበር. ስለዚህ ለእኛ እንዲቀርጹን ጽንሰ-ሐሳብ ሰጥቷል. አንድ እንዲቀርጹን አንድ መሠረታዊ ሞዴል አባል መውሰድ እና ተጨማሪ ትርጉም መስጠት ይችላሉ ይላል. ግትርነት መከፋፈል እና ማህበራት, ርስት ግንኙነት, ትምህርት, እና ክፍሎች ማራዘም ጥቅም ላይ ሊውሉ ይችላሉ.
ስእል 17; ድር እንዲቀርጹን ምሳሌ
ስእል 17 የድር ከምናውቀው ስዕል ያሳያል. አንድ ድረ ገጽ በተለምዶ ደንበኛ ላይ ሜዲቴራኒያን አገልጋዩ እና ነገሮች ላይ የሚያሄድ ነገሮች አለው. አንተ Web-based መተግበሪያዎችን ለመገንባት ከሆነ, ምን ደንበኛው ላይ እያሄደ ያለው እና አገልጋዩ በጣም አስፈላጊ ነው. ስለዚህ የሚያሳዩ ከምናውቀው ወይም አንድ ሙሉ ስብስብ አለን. ትንሹ መንኮራኩሮች በአገልጋዩ ላይ አሂድ ነገሮች ያመለክታሉ. ስለዚህ ልክ እኔ በአገልጋዩ ላይ ይሰራል ምን ማየት ይችላሉ ይህን ዲያግራም በመመልከት, ምን ደንበኛው ላይ ይሮጣል, እና ምን የንግድ ዕቃዎች እነሱ ጋር መታገል ያስፈልገናል.

“——————————————————————————————————————————————————

ترجمة الدعم: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”إن UML هي اللغة القياسية لتحديد، تصور، وبناء، وتوثيق جميع القطع الأثرية من نظام البرمجيات.””
آخر رسم تخطيطي
المكان المنطقي لبدء المشي من خلال بعض الرسوم البيانية UML هو من خلال النظر في الرسوم البيانية النشاط.
الشكل 2: مخطط آخر
وتشير الرسوم البيانية النشاط تدفق السيطرة. كما هو موضح في الشكل رقم 2، يمكنك أن ترى الأنشطة ممثلة على شكل مستطيلات مدورة. الأنشطة وعادة ما تكون الدول العمل â € “”أن الانتقال تلقائيا إلى الدولة القادمة بعد عمل كاملة. وشغل في دائرة يمثل بداية الرسم النشاط â € “”حيث تدفق يبدأ التحكم. تظهر التحولات كما هو موضح السهام كيف الانتقال من نشاط إلى آخر. تظهر القضبان تزامن كيف تحدث الأنشطة بالتوازي. يمكنني حراسة التحول الذي يقول “”أريدك أن تذهب إلى هذا النشاط إلا إذا كان هذا الشرط صحيحا””، وأنا يمكن أن تظهر لك حيث توقف. الآن إذا كنت من سن معينة، ربما عليك إلقاء نظرة على هذا المخطط النشاط والتفكير، “”هم â € | يشبه الرسم البياني.”” وهذا هو بالضبط ما هو عليه، إلا أنني لا تفعل ذلك بانخفاض في مستوى البرمجة. عادة، وأنا استخدم مخطط النشاط في وقت مبكر نسبيا في بلدي تحليل وتصميم عملية لاظهار سير العمل. أنا أيضا استخدامها لتظهر فيها كل من الحالات استخدامي قد يكون في أي نشاط لتوضيح ما حالة استخدام يجب أن يحدث. أود أيضا أن استخدام الرسوم البيانية النشاط لإظهار كيفية تدفق الأشياء بين حالات الاستخدام بلدي.
لكن واحدة من أشياء عظيمة عن UML هو تنوعها. وذلك في حين يمكنني استخدام الرسوم البيانية النشاط في بداية دورة حياة، يمكن للآخرين الاستفادة منها في مرحلة مختلفة تماما. رأيت الناس استخدام النشاط البيانية لأسفل على مستوى التصميم حيث كان لديهم مجموعة معقدة جدا من الخوارزميات لفئة معينة. وكثير من الناس استخدامها لإظهار تدفق بين أساليب فئة.
النظام. يتم تمثيل الجهات الفاعلة من الشخصيات عصا.
الشكل 4: الفاعلون
على سبيل المثال التي عملت لهذا مقدمة لUML هو نموذج صغير من نظام تسجيل بالطبع. حتى في هذه الحالة، فإن أول شيء أود أن تفعل عندما تبدأ عملية تحليل نظري هو أن نسأل، “”الذي هو ذاهب للتفاعل مع هذا النظام؟””
لنموذج تسجيل بالطبع، لدي المسجل، وهو أستاذ والطالب. وأود أيضا أن يكون لها نظام فوترة خارجي. تأهل نظام الفوترة هذا أيضا كعنصر فاعل. (انظر فاعل ليس من الضروري أن يكون الشخص € “”كان أي شيء أن يتفاعل مع النظام ولكن هو خارج النظام.)
وهناك حالة الاستخدام هو سلسلة من المعاملات ذات الصلة التي يقوم بها فاعل في النظام في الحوار. أو، لوضعها في اللغة الإنجليزية، وهي قضية استخدام عبارة عن قطعة من وظائف. وهنا يكمن المفتاح: أنها ليست وحدة البرامج â € “”هو شيء يقدم قيمة للالفاعل.
وتظهر حالات الاستخدام كما شكل بيضوي، وأسهل طريقة للعثور عليهم هو أن ننظر إلى كل من الجهات الفاعلة واسأل نفسك لماذا يريدون استخدام النظام. في حالتي، مسجل يجري للحفاظ على المناهج الدراسية، أستاذي هو الذهاب لطلب قائمة، ويحافظ على تلميذي الجدول الزمني، ونظام الفوترة بلدي يتلقى معلومات الفواتير. لذلك أنا خلق حالات الاستخدام بلدي من خلال النظر في ذلك من وجهة نظر العملاء ويسأل، “”لذلك، والممثل نظام سيد، لماذا كنت تريد استخدام النظام؟ ما هي القيمة التي يوفرها هذا النظام بالنسبة لك؟””
الخطوة التالية، مرة واحدة كنت قد حددت كيف الجهات الخاصة بك وسوف يتم التفاعل مع النظام، هو تأليف توثيق حالات استخدام الخاص. تحتاج كل حالة استخدامها لتكون موثقة مع تدفق الأحداث، ويتم ذلك من وجهة نظر الممثل وجهة نظر. يجب أن بالتفصيل ما يجب أن يوفر النظام إلى الممثل عندما يتم تنفيذ حالة الاستخدام. عادة سوف تظهر أشياء مثل كيف تبدأ حالة استخدام والتشطيبات. ما هي الأشياء التي لا يجب أن حالة استخدام القيام به؟ سيكون لديك التدفق الطبيعي للأحداث (ما أسميه “”الأيام السعيدة”” السيناريو)، حيث يعمل كل شيء. ثم ستحصل على تدفق غير طبيعي للأحداث، و “”يوم ممطر”” السيناريو. ماذا يحدث عندما لا يعمل النظام؟ لقد وجدت من خلال توثيق بلادي تدفق الأحداث التي دائما ما تبدأ مع الأيام السيناريو سعيد.
خذ على سبيل المثال، سيرا على الأقدام إلى ماكينة للصرف الآلي. يمكنك المشي إلى أجهزة الصراف الآلي وإدخال البطاقة. يسأل عن رقم PIN الخاص بك. عند إدخاله، ويطلب منك ما تريد القيام به. أنت تقول: “”أريد بعض المال.”” ما يطلب حيث ينبغي أن تؤخذ الاموال. كنت أقول ذلك لأعتبر من فحص الحساب الخاص بك. ويسأل كيف ذلك بكثير. أقول لكم $ 100.00. ثم يحدث السحر â € | فهو يوفر لك $ 100.00. ثم يسألك إذا كنت تريد معاملة أخرى. كنت أقول لا. فهو يوفر لك بطاقة ظهرك، ويتيح لك استلام، والصفقة قد انتهت. هذا هو السيناريو يوما سعيدا.
السيناريو الثاني. تذهب إلى أجهزة الصراف الآلي، إدراج بطاقة، وإدخال رقم التعريف الشخصي الخاص بك. أجهزة الصراف الآلي يخبرك انها PIN بشكل خاطئ. قمت بإدخال الرقم الخاص بك مرة أخرى. مرة أخرى يقال لك أن PIN غير صحيح. كنت في بلدي بالطبع سبيل المثال تسجيل، على سبيل المثال، يمكنك أن ترى أن هناك الكثير من “”إذا X ثم Y”” سير العمل. هذا هو المكان الذي تريد عميلك لمساعدتك. يعني اتفاق الحصول في وقت مبكر عميلك يفهم هذه السيناريوهات ويقول “”نعم، هذا هو ما نريد””. استخدام الحالات هي طريقة رائعة لضمان أن ما كنت بناء هو حقا ما يريد الزبون، لأنها تظهر الأطراف الفاعلة، وحالات الاستخدام، والعلاقات بينهما.
الشكل 5: استخدام حالة الرسم البياني
لذلك لدينا مخطط طيبة تظهر بوضوح لي ماذا؟ الجواب هو بسيط € “”هو المخطط الكبير الذي يدل على نظرة جيدة للنظام. وهو يبين ما هو خارج النظام (الفاعلين) وظيفة أن النظام يجب أن توفر (حالات الاستخدام). إذا كان هناك النظام القديم تحتاج إلى أن تأخذ في الاعتبار، وهنا حيث يمكنك التعامل معها. وأجبروني على العمل مع هذه الأنواع من واجهات في المشروع في وقت مبكر جدا يعني أنني لن تواجه احتمال الانتظار حتى الترميز يبدأ لمعرفة كيف انا ذاهب الى الحديث إلى هذا المربع الأسود الذي لا أستطيع أن أغير .
أكثر شيء واحد يجب أن تعرفه عن حالات الاستخدام هو استخدام حالة تحقيق. هذا هو “”كيف”” لاستخدام القضية. انها عادة دلو يحتوي على ثلاثة أنواع مختلفة من الرسوم البيانية: مخططات تسلسل، الرسوم البيانية والتعاون، ورسم تخطيطي لفئة أن نسميه عرض الطبقات المشاركة. استخدام انجازاتهم قضية هي في الأساس وسيلة لتجميع معا عددا من القطع الأثرية المتعلقة بتصميم من حالة الاستخدام.
تسلسل رسم تخطيطي
وتشير الرسوم البيانية تسلسل التفاعل الكائن مرتبة في التسلسل الزمني. يمكنني استخدام تدفق الأحداث لتحديد ما هي الأشياء والتفاعل وسوف تحتاج إلى إنجاز وظائف محددة من قبل تدفق الأحداث.
الشكل 6: مخطط تسلسل
ويبين الشكل 6 كيف يمكن لطالب بنجاح يحصل على إضافة إلى دورة تدريبية. الطالب (دعونا ندعو له جو) يملأ في بعض المعلومات ويقدم النموذج. ثم يتحدث النموذج إلى مدير ويقول “”إضافة جو لالرياضيات 101.”” مدير يروي الرياضيات 101 أن لديها لإضافة طالب. الرياضيات 101 يقول للقسم 1 “”تفتحون؟”” في هذه الحالة، القسم 1 ردود أنها مفتوحة، لذلك يقول الرياضيات 101 الباب 1 لإضافة هذا الطالب. مرة أخرى، تسلسل المخططات هي أدوات عظيمة في البداية لأنها تظهر لك وعميلك خطوة بخطوة ما يجب أن يحدث.
من ناحية تحليل للعرض، لقد وجدت على مر السنين أن مخططات تسلسل هي قوية جدا في مساعدتي دفع المتطلبات؛ خصوصا المتطلبات التي يصعب العثور عليها. متطلبات واجهة المستخدم، على سبيل المثال، كما هو معروف لأنك تبدو دائما للحصول على المتطلبات التي ليست فقط قابلة للاختبار. وهناك مطلب واجهة المستخدم الشائعة مثل هذا هو “”يجب أن يكون هذا النظام سهل الاستعمال.”” كم كنت قد اجتمعت كمبيوتر ودية؟ واحدة من فوائد هذه الأنواع من الرسوم البيانية هو أن كل خط القادمة من فاعل يمثل شخص، يخبرك بأن هناك شيئا في واجهة المستخدم الخاصة بك لديها لتوفير القدرة اللازمة من قبل هذا الشخص. وبعبارة أخرى، يمكنك استخدام الرسوم البيانية تسلسل لطرد متطلبات واجهة المستخدم قابلة للاختبار.
مخططات تسلسل هي، بالتالي، جيدة لإظهار ما يحدث، لطرد المتطلبات، والعمل مع العملاء. الذي يؤدي عادة إلى هذه المسألة، على الرغم من كم لا تحتاج إلى إنشاء؟ جوابي هو: “”حتى أنت تفعل ما فيه الكفاية.”” وأنت تسير لمعرفة عند القيام مخططات تسلسل أن تصل إلى نقطة حيث كنت لا تجد أي وجوه جديدة، عدم العثور على أي رسائل جديدة، وأنك تكتب نفس الشيء مرارا وتكرارا. في المثال من جو الانضمام الرياضيات 101، ونحن نعلم ان العملية ستكون هي نفسها إذا جو يريدون الانضمام التاريخ 101. لذلك، كقاعدة عامة، لا رسم تخطيطي للتسلسل لكل تدفق الأساسية لكل حالة الاستخدام. هل رسم تخطيطي تسلسل رفيع المستوى، والسيناريوهات الخطرة، وينبغي أن يكون كافيا. هذا هو عدد المخططات تسلسل أفعل.
لنتذكر هنا، هو أن رسم تخطيطي التعاون هو مجرد وجهة نظر مختلفة من سيناريو ويمكنك الذهاب ذهابا وإيابا بين الرسوم البيانية والرسوم البيانية تسلسل التعاون للحصول على الرأي القائل بأن يوضح أفضل وجهة نظرك.
في بعض الأحيان، قد تسمع عبارة “”مخططات التفاعل””. أحيانا الناس سوف تشير مجتمعة إلى رسم تخطيطي التعاون ورسم تخطيطي للتسلسل كما مخطط التفاعل.
رسم تخطيطي لفئة
وهناك فئة هي عبارة عن مجموعة من الكائنات مع هيكل موحد، والسلوك المشترك، والعلاقات العامة، ودلالات مشتركة. يمكنك العثور عليها عن طريق فحص الكائنات في تسلسل والتعاون الرسوم البيانية، ولها تمثيل في UML على شكل مستطيل مع ثلاث مقصورات.
الرقم 8: فصول
تظهر المقصورة الأولى اسم الفئة، والثاني يظهر هيكلها (سمات)، ويدل على ثلث سلوكها (العمليات). هذه المقصورات يمكن قمعها، ومع ذلك، يمكنك أن ترى مجرد اسم، مجرد الاسم والصفات، أو كل ثلاثة. شيء واحد يجب أن نعرف أيضا أن من المهم، عند تسمية الطبقات، واستخدام مفردات المجال واختيار المعيار. لهذا المثال، دروسي هي كل الأسماء المفردة التي تبدأ بحرف كبير. قد اخترت القيام به بشكل مختلف، وهذا لا يهم. ما يهم هو أنه قبل المشروع الخاص بك يمكنك اختيار مستوى والعصا معه حتى أن كل شيء متناسقة عبر المشروع.
الطبقة رسم تخطيطي لتظهر لك طبيعة ثابتة من النظام الخاص بك. تظهر هذه المخططات وجود الطبقات وعلاقاتهم في العرض المنطقي للنظام. سيكون لديك العديد من المخططات فئة في نموذج.
عناصر النمذجة UML وجدت في مخططات الطبقة ما يلي:
الطبقات وهيكلها والسلوك.
علاقات الارتباط، والتجميع، التبعية، والميراث.
مؤشرات تعدد والملاحة
أسماء الدور.
نلقي نظرة على الشكل 9. يظهر هذا الرسم البياني العمليات (السلوك): ما كائن في تلك الفئة يمكن القيام به. أجد عمليات بلدي من خلال النظر في بلدي التفاعلات الرسوم البيانية.
الرقم 9: العمليات
أنا هنا أقوله أنني بحاجة إلى أن تكون قادرة على طرح مدير التسجيل لإضافة الطالب الرياضيات
101. وهذا يحدث لترجمتها إلى عملية تسمى “”addCourse.””
ويمثل هيكل فئة من خصائصها. فكيف أجد سمات بلدي؟ من خلال التحدث إلى خبراء المجال. من خلال النظر في متطلبات بلدي. في بلدي على سبيل المثال، أتعلم أن كل التخصصات التي يدرسها لديها عدد، موقع، ووقت واحد. وهذا يترجم إلى ثلاث صفات.
الطبقات. (ممثلة في UML كما خط يربط بين الفئات ذات الصلة مع الماس القادم إلى فئة تمثل كل).
â € ¢ التبعية â € “”شكل أضعف تظهر العلاقة بين العميل والمورد حيث لا يكون لدى العميل معرفة الدلالات من المورد. وتقول تبعية “”أنا بحاجة إلى خدمات، ولكن أنا لا أعرف أنك موجود.”” (ممثلة في UML كخط متقطع لافتا من العميل إلى المورد.)
العثور على العلاقات، مرة أخرى، وأنا أعود إلى بلدي تسلسل الرسم التخطيطي. إذا تحتاج كائنين إلى “”التحدث””، يجب أن يكون هناك وسيلة للقيام بذلك (أي علاقة بين صفوفهم).
أنا عادة تبدأ وجعل كل شيء جمعية ما. كما أنا أفعل المزيد من التحليل، ربما أجد لدي تجميع لأنني ذاهب لدينا لرعاية علاقة بين الوالدين والطفل. عندما ندخل في مرحلة التصميم، أجد أنني قد لا تحتاج إلى وجود علاقة لشخص آخر هو ذاهب لتمرير هذا الكائن إلى واحدة من أساليبي â € “”حتى أنا جعله التبعية.
الرقم 11: العلاقات
في الشكل 11 ترى هذه العلاقات. كما الرابطة يقول البروفيسور يمكن الحديث في هذا الطرح غولف، ويقدم الدورة التدريبية يمكنك التحدث الى الأستاذ. ويمكن البدء في الرسائل، ويمكن أن تدفق البيانات من أي اتجاه. ويرد التجميع عن طريق الحصول على الماس نحو â € كله “”في هذه الحالة يتم إجراء دورة تتكون من الدورات التدريبية. ان السبب في ذلك تجميع يكون لنقول للمطورين لي أنهم إذا تخلص من هذه الدورة التدريبية، وأنها سوف ربما يجب أن نفعل شيئا خاصا مع الدورات التدريبية. وتظهر تبعيات كخط متقطع. وهو يقول أن مدير التسجيل يعتمد على الجدول الزمني للخوارزمية أن تفعل شيئا. جدول خوارزمية إما معلمة إلى إحدى الطرق أو يعلن محليا من قبل واحدة من أساليب مدير التسجيل.
تعدد والملاحة
تعرف تعدد كيف تشارك العديد من الكائنات في العلاقة. هو عدد من الحالات من فئة واحدة تتعلق مثيل واحد من فئة أخرى. لكل الجمعيات والتجمع، وهناك نوعان من القرارات تعدد لجعل: واحد لكل نهاية العلاقة. ويمثل تعدد كرقم ويستخدم * لتمثيل عدد وافر من كثير.
الرقم 12: تعدد والملاحة
يرتبط واحد كائن أستاذ إلى كائنات يقدم دورة صفر إلى أربعة. يرتبط دورة واحدة تقدم كائن إلى كائن بالضبط أستاذ واحد. أنا استخدم هذا أن ننظر إلى والتأكد من أن هذا يعالج متطلبات بلدي. يمكن أن أكون الاكتتاب المقرر وأن الفريق يدرس من قبل مجموعة من الأساتذة؟ لا، لأن هذا يقول أنا يمكن أن يكون فقط أستاذ واحد. يمكن أن أكون أستاذ ويكون في اجازة؟ نعم، لأن هذا يقول عندي الصفر كما حمل بالطبع ممكن. يمكنني استخدام تعدد في كثير من الأحيان لمساعدتي في بدء التقاط وتنفيذ قواعد عملي. إذا كان لديك، على سبيل المثال، قاعدة عمل يفيد بأنه يجب أن يكون لديك على الأقل 3 طلاب ولا يزيد عن 10 لدورة التي سيتم تقديمها في الفصل الدراسي، وهذه الأرقام تعدد تقول لي لقد أدرجت هذه القاعدة الأعمال في هذه الخطة.
يظهر الملاحة بسهم، وعلى الرغم من جمعيات وتجمعات هي ثنائية الاتجاه بشكل افتراضي، غالبا ما يكون من المرغوب فيه أن يقيد الملاحة البحرية في اتجاه واحد. عندما يقتصر التنقل، يتم إضافة رأس السهم يشير إلى الاتجاه الملاحية. واحدة من الاشياء التي اقوم خلال تحليل وتصميم المراحل هو أن ننظر في ما أريد أن يكون أحادي الاتجاه. من خلال وضع السهم في هذا الرسم البياني، وأنا أقول أن مدير التسجيل يمكن أن ترسل رسالة للدورة، لأنه يعرف وجود دورة. ولكن بالطبع لا يوجد لديه فكرة أن وجود مدير التسجيل، وبالتالي فإن بالطبع لا يمكن الشروع رسالة. الآن يمكن للبيانات تتدفق بينهما. على سبيل المثال مدير التسجيل يمكن أن يطلب من دورة إذا كان مفتوحا وملعب يمكن القول أنه. ولكن فقط لمدير التسجيل يمكن أن تبدأ تلك المحادثة.
من الواضح أن الهدف هنا هو الحصول على أكبر عدد ممكن من الأسهم كما يمكنك بحلول الوقت الذي تنتهي من تصميم، لأنه نظام أسهل بكثير للحفاظ على الميراث يظهر مع مثلث. هذا يدل على أن الأستاذ هو تسجيل المستخدم، كما هو الطالب. الآن، كلمة تحذير. الميراث هو مفيد، ومع ذلك، فإن الهدف من ذلك هو عدم استخدام الكثير من الميراث النظام الخاص بك سوف تسمح. رأيت بعض الأنظمة وحشية حقا حيث كان الإرث 17 مستويات عميقة. إذا غيروا شيء واحد، أصبح كارثة. لذلك وبحكم التجربة هو استخدام الميراث فقط عندما تفعل حقا لها الوضع الميراث.
الانتقال مخططات الدولة
ويظهر الرسم البياني انتقال الدولة من تاريخ حياة فئة معينة. فإنه يدل على الأحداث التي تتسبب في الانتقال من دولة إلى أخرى، والإجراءات التي تنجم عن تغيير حالة.
الرقم 14: الدولة الرسم البياني الانتقال
يمكنني استخدام الرسوم البيانية انتقال الدولة لفئات الكائن الذي عادة ما يكون الكثير من السلوك الديناميكي. الزر على € A | زر إيقاف. أنا لن تفعل مخطط الدولة لذلك. لكن طبقات الكائن التي لديها الكثير من السلوك الديناميكي، وأنا ربما ستكون لدينا للنظر في ولايات الكائنات.
أبدأ من خلال إظهار الدولة، وهو مثلث مدورة. أنا يمكن أن يكون لها دول البداية، وأنا يمكن أن يكون لها الدول المحطة، والتي كما هو موضح الثيران العينين. أنا يمكن أن يكون أيضا الانتقال بين الدول، أو التحولات حارس (الأشياء التي تحدث عندما فقط عندما يكون الشرط صحيحا)، أو الأشياء التي تحدث عندما أكون داخل الدولة. أنا أنظر إلى هذا المخطط، وانظر الرسم البياني انتقال الدولة لذبيحة بالطبع. ويبدأ في ولاية التهيئة، وأود البقاء في تلك الدولة حتى أحصل على رسالة “”إضافة الطالب””. عندما أحصل على تلك الرسالة، أنا وضعت حساباتي الطالب من الصفر، وأنا الانتقال إلى دولة المفتوحة. سترى في الشكل 14 أن لدي دخول، والسبب انه هناك هو أنني هناك طريقتان ليحصل داخل تلك الدولة. وتقول أنه مهما كنت تأتي إلى الدولة، وأنا أريد منك أن تسجل الطالب. عند الخروج تلك الدولة، يتغير عدد لتتبع عدد الطلاب في هذه الدورة. أنا يمكن أن تبقي مضيفا الطلاب حتى أحصل على 10، ثم أذهب إلى دولة إغلاق. وبمجرد الانتهاء من الدورة، والانتقال إلى حالة توقف. بغض النظر عن مكاني ثم، إذا حصلت على الغاء التحول حدث، وأنا تخطر طلابي ومن ثم الانتقال إلى دولة توقف.
لطبقات الكائن التي لديها الكثير من السلوك الديناميكي، فإنه يستحق ذلك جيدا للقيام مخطط الدولة للحصول على التعامل مع كل ما يجب أن يحدث. اسأل نفسك ما الذي يحدث عندما أحصل على الرسالة؟ ماذا أفعل عندما أحصل على الرسالة؟ ما هي الرسائل لأنني في إرساله؟ وهناك الكثير من هذه الرسائل أصبحت عمليات من فئة الكائن، كما في هذا المثال حيث إضافة الطالب العملية. وهناك الكثير من هذه الأعمال، مثل وضع العد، تزايد عدد، والتحقق من عدد، كل هذه أصبحت عمليات خاصة من تلك الفئة كائن معين والرسم التخطيطي للدولة هو المكان الذي أرى ذلك.
كيف يمكنك أن تعرف إذا كان لديك فئة الكائن الديناميكية؟ مرة أخرى، نعود إلى مخططات تسلسل. إذا كان لديك فئة الكائن هذا على الكثير من الرسوم البيانية تسلسل وهو الحصول على وإرسال الكثير من الرسائل، وهذا مؤشر جيد على انها فئة الكائن ديناميكية إلى حد ما وربما ينبغي أن يكون مخطط الدولة لذلك. أيضا لتجمعات، حيث لديك كل من أجزائه، أفعل مخطط الدولة لكل العموم الكلي. أفعل هذا في الغالب لأن ذلك كله الكلي غالبا ما يكون مسؤولا عن إدارة الرسائل، مما يجعل من دينامية.
الرسوم البيانية عنصر
بالطبع لا يوجد نظام يمكن أن يبنى دون الأخذ بعين الاعتبار العالم المادي. هذا هو المكان الذي تأتي فيه المخططات المكونة في. وهي تستخدم لتوضيح المنظمات والتبعيات بين مكونات البرامج، بما في ذلك مكونات شفرة المصدر، مكونات وقت التشغيل، أو عنصر قابل للتنفيذ. المكونات يظهر على شكل مستطيل كبير مع اثنين من المستطيلات الصغيرة على الجانب، كما رأينا في الشكل 15.
الرقم 15: مكونات
وتمثل تلك الأشياء المستديرة واجهات (غالبا ما تسمى مصاصة التدوين). في هذه الحالة، فإنها تدل على أن Register.exe يعتمد على واجهات لكل من Course.dll وPeople.dll. وهذا يعني إذا تغيرت هذه الواجهات، وسوف تؤثر على Register.exe. وأنا أعلم أن هناك هذه القاعدة عندما كنت بناء الواجهات التي تقول “”لا يجوز تر تغيير واجهة””. ولكن لا أحد يعمل في الواقع حيث يتم فرض هذه القاعدة؟ هذا المخطط يخبرنا ما اجهات يتم استخدامها من قبل ما تعمل التنفيذية على معالجات بلدي.
الشكل 16: مخطط الوزع
توسيع UML
آخر شيء أريد أن أؤكد حول UML هو أنه يمكن تمديدها. عندما بنوا UML، أدركوا بحكمة جدا أنه لا يوجد أي الطريقة التي يمكن أن تؤدي إلى التدوين التي يمكن إرضاء كل الناس كل الوقت. حيث اعطونا مفهوم الصورة النمطية. وتقول الصورة النمطية يمكنني أن تأخذ عنصر النمذجة الأساسي وإعطائها المزيد من معنى. ويمكن استخدام الصور النمطية لتصنيف وتمديد الجمعيات، والعلاقات الميراث، والطبقات، والمكونات.
الرقم 17: الويب سبيل المثال النمطي
ويبين الشكل 17 الرسم البياني القوالب النمطية على شبكة الانترنت. صفحة ويب وعادة الاشياء التي تعمل على الخادم والاشياء التي يتم تشغيلها على العميل. إذا كنت بناء التطبيقات على شبكة الإنترنت، ما يعمل على العميل والخادم هو من أهمية حيوية. لذلك لدينا مجموعة كاملة من الصور النمطية التي تظهر ذلك. تمثل عجلات صغيرة الأشياء التي تعمل على الخادم. وذلك فقط من خلال النظر في هذا المخطط واحد أستطيع أن أرى ما يتم تشغيله على الملقم، ما يعمل على العميل، وما الكائنات الأعمال لديهم للتعامل معها.

“——————————————————————————————————————————————————

Support թարգմանությունը: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

«The UML է ստանդարտ լեզուն ճշտելու համար, visualizing, կառուցման, եւ documenting բոլոր artifacts մի ծրագրային համակարգի””
Ակտիվություն դիագրամների
Տրամաբանական տեղ է սկսել քայլել միջոցով որոշ UML դիագրամների են նայում գործունեության դիագրամների.
Գծապատկեր 2 Ակտիվություն դիագրամ
Ակտիվություն դիագրամների ցույց են տալիս հոսքը վերահսկողությունից. Ինչպես երեւում է Գծապատկեր 2, դուք կարող եք տեսնել գործունեությունը ներկայացված է որպես կլորացվում ուղղանկյուններ: Տուրիզմ են սովորաբար ակցիան պետություններ â € “”հայտարարում է, որ անցումը ինքնաբերաբար դեպի հաջորդ պետությանը ակցիայից հետո ավարտված է. Լրացված շրջանակի ներկայացնում սկիզբը գործունեության դիագրամ â € “”, որտեղ հոսքը հսկողության սկսվում. Transitions ցուցադրվել որպես Ռադիո ցույց տալ, թե ինչպես Դուք տեղափոխվելու գործունեության ակտիվության: Համաժամացման բարեր ցույց տալ, թե գործողությունները տեղի են ունենում զուգահեռ: Ես կարող եմ պահակ անցումը, որ ասում է «Ես ուզում եմ, որ դուք պետք է գնալ: Այս մասին, միայն այն դեպքում, եթե այդ պայմանը ճիշտ է», եւ ես կարող եմ ցույց տալ, թե որտեղ է այն դադարում: Հիմա, եթե դուք որոշակի տարիք, դուք, ամենայն հավանականությամբ, նայում այս գործունեության դիագրամ, եւ կարծում եմ, «hmm â € |, որ կարծես հոսքի աղյուսակում.”” Եւ դա հենց այն է, բացառությամբ, ես չեմ անում այն ներքեւ ծրագրավորման մակարդակով: Որպես կանոն, ես օգտագործել ակտիվության դիագրաման բավականին շուտ իմ վերլուծության եւ նախագծման գործընթացի շոու-բիզնես աշխատանքի արդյունքում: Ես պետք է նաեւ օգտագործել դրանք, որպեսզի ցույց, որտեղ յուրաքանչյուրը իմ օգտագործման դեպքերի, կարող է լինել մի գործունեությամբ ցույց են տալիս, թե ինչ օգտագործման դեպքը պետք է տեղի ունենա: Ես նաեւ օգտագործել գործունեության դիագրամների ցույց տալ, թե ինչպես է ամեն ինչ հոսում է իմ միջեւ օգտագործման դեպքերի.
Բայց մեկը մեծ բաների մասին UML է նրա բազմակողմանիություն. Այնպես որ, երբ ես օգտագործել գործունեություն դիագրամների սկզբին է lifecycle, մյուսները կարող են օգտագործել դրանք տարբեր փուլում ամբողջությամբ. Ես տեսել եմ, որ մարդիկ օգտագործում ակտիվությունը դիագրամների ցած է նախագծային մակարդակը, որտեղ նրանք ունեն շատ բարդ շարք ալգորիթմների համար որոշակի դասի. Եվ շատ մարդիկ օգտագործում է նրանց ցույց տալ հոսքը միջեւ մեթոդների մի դասի.
համակարգը. Դերեսաններ ներկայացված են որպես փայտը գործիչների:
Նկար 4: Դերեսաններ
Օրինակը, որ աշխատել եմ մինչեւ այս ներածություն UML մի քիչ մոդել, իհարկե գրանցման համակարգի. Այնպես որ, այս դեպքում, առաջին բանը, որ ես անել, երբ սկսում իմ վերլուծությունը գործընթաց է հարցնել, «ով պատրաստվում է համագործակցել այս համակարգով»:
Համար, իհարկե, գրանցման մոդելի, ես պետք է ռեեստրավարի պրոֆեսորի, մի ուսանող. Ես նաեւ պետք է արտաքին բիլինգային համակարգը: Այս բիլինգային համակարգը նաեւ որակում որպես դերասան: (Տես, դերասան չունի լինել այն անձը, â € “”դա ոչինչ, որ համագործակցում է համակարգի, բայց դուրս է համակարգի.):
A օգտագործման դեպքը մի հաջորդականությունը գործարքների կողմից իրականացվող դերասան համակարգում է երկխոսության: Կամ, ինչպես նաեւ այն, անգլերեն լեզվով, օգտագործումը գործը կտոր ֆունկցիոնալ. Եվ ահա բանալին այն է, որ ոչ մի ծրագրային մոդուլը â € “”, դա մի բան է, որ ապահովում է արժեք է դերասան:
Օգտագործեք դեպքերը ցույց են տալիս, քանի որ ovals, եւ ամենահեշտ ճանապարհը գտնել դրանք պետք է նայում յուրաքանչյուր ձեր դերասանների եւ հարցրեք ինքներդ ձեզ, թե ինչու են նրանք ուզում են օգտագործել համակարգը: Իմ դեպքում, իմ registrar ն պատրաստվում է պահպանել ուսումնական ծրագիրը, իմ պրոֆեսոր է, պատրաստվում է պահանջել անվանացանկով, իմ աշակերտը պահպանում ժամանակացույցը, եւ իմ բիլինգային համակարգը ստանում է բիլինգ տեղեկություններ. Այնպես որ, ես ստեղծել իմ օգտագործման դեպքերը է նայում դրա հաճախորդների տեսանկյունից եւ հարցնում », ուստի, mister համակարգ դերասան, ինչու եք ուզում օգտագործել այդ համակարգը: Ինչ արժեք չունի այս համակարգը ապահովում է ձեզ».
Հաջորդ քայլը, երբ դու նույնացնել թե ինչպես է ձեր դերասանները պիտի շփվել համակարգի, այն է փաստաթղթային Ձեր օգտագործման դեպքերը: Յուրաքանչյուր օգտագործման դեպքը պետք է փաստաթղթավորվեն, ինչպես նաեւ հոսքի իրադարձությունների, եւ դա արվում է դերասանի տեսանկյունից: Այն պետք է մանրամասն, թե ինչ համակարգ պետք է ապահովի, որ դերասանի, երբ օգտագործման դեպքում կատարվում: Որպես կանոն, դա ցույց կտա, որ նման բաներ, թե ինչպես է օգտագործման դեպքը սկսվում եւ ավարտվում: Ինչ բաներ չի, որ օգտագործումը դեպքը պետք է անել. Դուք պետք է նորմալ հոսքը իրադարձությունների (ինչ ես կոչում եմ «երջանիկ օրեր» սցենարը), որտեղ ամեն ինչ աշխատում է: Ապա դուք կստանաք աննորմալ հոսքը միջոցառումներին, «Անձրեւոտ օր» սցենարը: Ինչ է տեղի ունենում, երբ համակարգը չի աշխատում. Ես գտա կողմից documenting իմ հոսքը միջոցառումների, որոնք ես միշտ սկսել է երջանիկ օրեր սցենարով.
Վերցրեք որպես օրինակ, քայլել մինչեւ մի Բանկոմատ: Դուք քայլել մինչեւ բանկոմատին եւ տեղադրեք Ձեր քարտը: Այն հարցնում է Ձեր PIN համարը. Դուք մուտք գործել այն, եւ դուք խնդրել, թե ինչ եք ուզում անել: Դուք ասում եք, «Ես ուզում եմ որոշակի գումար»: Այն պահանջում է, որտեղ գումար է պետք վերցված: Դուք ասեք այն վերցնել այն Ձեր ընթացիկ հաշիվ. Այն պահանջում է, թե որքան: Դուք ասում եք, $ 100.00. Այնուհետեւ կախարդական տեղի է ունենում € |, այն հնարավորություն է տալիս Ձեզ $ 100.00. Ապա հարցնում է, եթե ցանկանում եք մեկ այլ գործարք: Դուք ասում եք, ոչ: Այն հնարավորություն է տալիս ձեզ ձեր քարտը ետ, Ձեզ հնարավորություն է տալիս ստացական, իսկ գործարքը ավարտվել է. Դա է ուրախ օր սցենարը.
Երկրորդ սցենարը. Դուք գնալ մինչեւ բանկոմատում, մտցրեք Ձեր քարտը, եւ մուտքագրեք Ձեր PIN- ը: Բանկոմատը պատմում է ձեզ, որ դա սխալ է PIN: Դուք մուտքագրեք Ձեր հեռախոսահամարը կրկին. Կրկին դուք ասել, որ PIN սխալ է: Դուք իմ իհարկե գրանցման օրինակ, օրինակ, դուք կարող եք տեսնել, որ կան շատ «Եթե X ժամանակվա y« workflows: Ահա թե որտեղ դուք ցանկանում եք ձեր հաճախորդին, որը կօգնի ձեզ դուրս. Ինչից համաձայնագիրը դեռ վաղ նշանակում է, ձեր հաճախորդը հասկանում է այդ սցենարները, եւ ասում է, «այո, սա այն է, ինչ մենք ուզում ենք»: Օգտագործեք դեպքեր են մեծ ճանապարհ է ապահովել, որ այն, ինչ դուք ցանկանում եք կառուցել իսկապես, ինչ հաճախորդը ցանկանում է, քանի որ նրանք ցույց են տալիս դերասաններին, օգտագործման դեպքերը, եւ դրանց միջեւ եղած հարաբերակցությունը:
Նկար 5: Օգտագործել գործը դիագրաման
Այնպես որ, մենք ունենք մի մեծ դիագրամ, որը գրաֆիկորեն ցույց տալ, թե ինչ? Պատասխանը շատ պարզ է â € “”, դա մի մեծ դիագրամ, որը ցույց է տալիս մի լավ ակնարկ համակարգի: Դա ցույց է տալիս, թե ինչ է դուրս համակարգում (դերասաններ) եւ ֆունկցիոնալությունը, որ համակարգը պետք է ապահովի (օգտագործման դեպքերը): Եթե կա մի ժառանգություն է համակարգը, դուք պետք է հաշվի առնել, ահա, որտեղ դուք զբաղվել դրա հետ: Ստիպելով ինձ հետ աշխատելու այդ տեսակի ինտերֆեյս շատ վաղ է նախագծի նշանակում է, որ ես չեմ կարող կանգնած հեռանկարով սպասում, մինչեւ կոդավորմամբ սկսում է պարզել, թե ինչպես ես պատրաստվում եմ խոսել այդ սեւ արկղը, որ ես չեմ կարող փոխել ,
Եվս մեկ բանը, դուք պետք է իմանա, օգտագործման մասին դեպքերում օգտագործման դեպքում իրացումը: Սա է «ինչպեսը» օգտագործման դեպքը: Դա սովորաբար մի դույլ, որը պարունակում է երեք տարբեր տեսակի դիագրամների `հաջորդականությունը դիագրամների, համագործակցություն դիագրամները, եւ մի դասի դիագրամ, որը մենք անվանում ենք տեսակետը մասնակից դասերի: Օգտագործման դեպքում realizations են հիմնականում մի միջոց խմբավորման համատեղ մի շարք artifacts առնչվող նախագծման օգտագործման դեպքում:
հաջորդականությունը դիագրամների
Հաջորդականությունը դիագրամների ցույց են տալիս, object փոխազդեցության կազմակերպվում է ժամանակային հաջորդականությամբ. Ես կարող եմ օգտագործել հոսքը իրադարձությունների որոշելու, թե ինչ օբյեկտներ եւ փոխազդեցությունների ես պետք է իրականացնել ֆունկցիոնալությունը նշված է հոսքի իրադարձությունների:
Նկար 6: հետեւողականություն դիագրամ
Նկար 6 ցույց է տալիս, թե ինչպես է մի ուսանող հաջողությամբ ստանում ավելացվել դասընթացի: Ուսանողը (եկեք զանգահարել նրան Joe) լրացնում է որոշ տեղեկությունների եւ ներկայացնում ձեւը: Ձեւը ապա խոսում է կառավարչի եւ ասում է “”Ավելացնել Joe է Math 101.« Կառավարիչը պատմում Մաթեմատիկա 101 է, որ պետք է ավելացնել մի ուսանող: Մաթեմատիկա 101 ասում է բաժնի 1 «Դուք բացել». Այս դեպքում, Բաժին 1 պատասխան, որ իրենք բաց են, այնպես որ, Math 101 պատմում բաժինը 1 ավելացնել այս ուսանողին: Կրկին, հաջորդականությունը դիագրամների են մեծ գործիքներ սկզբում, քանի որ նրանք ցույց կտա ձեզ, եւ ձեր հաճախորդների քայլ առ քայլ, թե ինչ պետք է տեղի ունենա:
– Ից վերլուծական տեսանկյունից, ես գտա տարիների ընթացքում այդ հաջորդականությունը դիագրամների են շատ հզոր է օգնել ինձ քշել պահանջները; հատկապես պահանջները, որոնք դժվար է գտնել. Ինտերֆեյսի պահանջները, օրինակ, վատ համբավ ունեն, քանի որ դուք միշտ կարծես ստանալ պահանջներ, որոնք պարզապես չեն testable: Մի ընդհանուր UI պահանջը նման է «Այս համակարգը պետք է լինի օգտագործողի բարեկամական»: Ինչպես ձեզանից շատերը հանդիպել է ընկերական համակարգիչ: Մեկը առավելությունները այդ տեսակների դիագրամների այն է, որ յուրաքանչյուր գիծը գալիս որպես դերասան, որը ներկայացնում է մարդուն, – պատմում է ձեզ, որ ինչ-որ բան է ձեր միջավայրի ունի տրամադրել մի կարողություն, որն անհրաժեշտ է այդ անձի. Այլ կերպ ասած, դուք կարող եք օգտագործել հաջորդականությունը դիագրամների է դուրս քշել testable ինտերֆեյսի պահանջները:
Հաջորդականությունը դիագրամների են, հետեւաբար, լավ ցույց տալու համար, թե ինչ է կատարվում, վարելու պահանջները, եւ աշխատում է հաճախորդների. Որ սովորաբար հանգեցնում է այն հարցին, սակայն, թե ինչպես շատերը դուք պետք է ստեղծել. Իմ պատասխանն է, «քանի դեռ դուք բավարար չեն»: Դու պատրաստվում է պարզել, թե երբ դուք անում եք հաջորդականությունը դիագրամների, որ դուք հասնել մի կետի, որտեղ դուք չեք գտնելու որեւէ նոր առարկաներ, չգտնելով որեւէ նոր հաղորդագրությունները, եւ որ դուք մուտքագրում նույն բանը, կրկին ու կրկին. Ի օրինակով Joe միանալով Math 101, մենք սովորում ենք, որ գործընթացը պետք է նույնը լինի, եթե Joe ցանկանում է միանալ պատմություն 101. Այնպես որ, գերակայության thumb, անել մի հաջորդականություն դիագրամ յուրաքանչյուր հիմնական հոսքի յուրաքանչյուր օգտագործման դեպքում. Անել մի հաջորդականություն դիագրամ բարձր մակարդակով, ռիսկային սցենարներ, եւ որ պետք է լինի բավարար: Ահա թե ինչպես շատերը հաջորդականությունը դիագրամների ես անել:
է հիշել այստեղ, այն է, որ համագործակցությունը դիագրամ է ընդամենը մի ուրիշ տեսք սցենարով, եւ դուք կարող եք գնալ ետ եւ առաջ միջեւ հաջորդականությունը դիագրամների եւ համագործակցության դիագրամների են ստանալ այն տեսակետը, որը լավագույնս ցույց է ձեր կետը.
Երբեմն, դուք կարող եք լսել արտահայտությունը «Փոխգործակցություն դիագրամների»: Երբեմն մարդիկ հավաքականորեն վերաբերում է համագործակցության դիագրամ եւ հաջորդականությունը դիագրամ որպես փոխգործակցության դիագրամ:
Class դիագրամների
A դասի մի հավաքածու օբյեկտների ընդհանուր կառուցվածքի, ընդհանուր վարքի, ընդհանուր հարաբերությունների եւ ընդհանուր իմաստաբանություն: Դուք գտնել դրանք քննելով օբյեկտները հաջորդականությամբ եւ համագործակցության դիագրամների, եւ նրանք ներկայացված են UML որպես ուղղանկյան երեք compartments.
Նկար 8: Դասեր
Առաջինը կուպե ցույց է տալիս դասի անունը, իսկ երկրորդը ցույց է տալիս իր կառուցվածքը (հատկանիշներ), իսկ երրորդը ցույց է տալիս իր վարքագիծը (գործառնություններ): Այս compartments կարելի ճնշել, սակայն, այնպես որ դուք կարող եք տեսնել միայն անունը, պարզապես անունը եւ ատրիբուտները, կամ բոլոր երեքը: Մի բան, որ դուք պետք է նաեւ իմանալ, որ դա կարեւոր է, երբ անվանելու դասեր է, օգտագործել բառապաշարը տիրույթում եւ վերցնել մի չափանիշ: Համար, այս, օրինակ, իմ դասերն են բոլոր եզակի գոյականներ, որոնք սկսվում են մեծատառով. Դուք կարող եք ընտրել է դա անել, այլ կերպ, եւ որ ոչ մի նշանակություն չունի: Ինչ է այն է, որ նախքան ձեր ծրագրի դուք վերցնել մի չափանիշ, եւ մնում է այն, այնպես, որ ամեն ինչ չէ, հետեւողական են նախագծին:
Մանրամասն դիագրամների ցույց տալ ձեզ ստատիկ բնույթը ձեր համակարգի. Այս դիագրամների ցույց են տալիս, դասակարգերի գոյությունը եւ նրանց հարաբերությունների մեջ տրամաբանական տեսակետից մի համակարգ. Դուք կունենաք շատ կարգի դիագրամների մի մոդելի.
The UML մոդելավորման տարրերը հայտնաբերվել է դասի դիագրամների ներառում:
Դասեր եւ դրանց կառուցվածքը եւ վարքագիծը:
Association, ագրեգացման, կախվածության, եւ ժառանգման հարաբերություններ:
Բազմազանությունը եւ նավիգացիոն ցուցանիշները
Դերը անունները.
Take a look at Նկար 9. Այս դիագրամ ցույց է տալիս, գործարքների (վարքը), թե ինչ օբյեկտ է տվյալ դասի կարող է անել: Ես գտնում եմ, իմ գործողություններ նայում իմ փոխազդեցություններ դիագրամների.
Նկար 9: Operations
Այստեղ ես ասում եմ, որ ես պետք է կարողանանք հարցնել գրանցման կառավարչին է ավելացնել ուսանողին Math
101. Այն պատրաստվում է թարգմանել որպես գործողության, որը կոչվում է «addCourse.””
Կառուցվածքը դասի ներկայացված է իր ատրիբուտներով: Այսպիսով, ինչպես կարող եմ գտնել իմ հատկանիշներ. Ըստ խոսում Դոմեյն փորձագետների: Են նայում իմ պահանջներին. Իմ, օրինակ, ես սովորում եմ, որ յուրաքանչյուր Իհարկե ընծայ ունի մի շարք, մի վայր, եւ ժամանակ: Այս թարգմանում են երեք հատկանիշների.
դասեր: (Ներկայացված UML որպես գծի կապող համապատասխան դասեր հետ ադամանդագործության հաջորդ դասին ներկայացնող ամբողջ)
â € ¢ կախվածության â € “”ավելի թույլ ձեւը ցույց միջեւ հարաբերությունները հաճախորդի եւ մատակարարների, որտեղ հաճախորդը չունի իմաստային գիտելիքները մատակարարի: A կախվածությունը ասում է «ես պետք է ձեր ծառայությունները, բայց ես չգիտեմ, թե որ դուք կաք:»: (Ներկայացված UML որպես գծիկներով մատնացույց է հաճախորդի մատակարարին)
Գտնել հարաբերություններ, մեկ անգամ եւս, որ ես վերադառնալ իմ հաջորդականության դիագրամ: Եթե երկու օբյեկտների համար անհրաժեշտ է «խոսել», պետք է լինի միջոց է դա անել (այսինքն, մի հարաբերություն նրանց միջեւ դասերի):
Ես սովորաբար սկսում են, եւ ամեն ինչ միավորում է: Քանի որ ես եմ անում ավելի շատ վերլուծություններ, ես կարող եմ գտնում եմ, պետք է ագրեգացման, քանի որ ես պատրաստվում եմ պետք է հոգ տանել մի ծնող-երեխա հարաբերություններում. Երբ ես ստանալ մեջ նախագծման փուլում, ես գտնում եմ, որ ես կարող եմ պետք չէ որեւէ միավորման, քանի որ ուրիշի, որը պատրաստվում է անցնել այդ օբյեկտը մեջ մեկը իմ մեթոդների â € “”, այնպես որ ես այն մի կախվածություն:
Նկար 11: Հարաբերություններ
Ի Նկար 11 տեսնում եք այդ հարաբերությունները: Քանի որ ասոցիացիայի ասում է, որ պրոֆեսոր կարող են խոսել ընթացքը ընծա, եւ, իհարկե, առաջարկի, կարող խոսել պրոֆեսոր: Հաղորդագրությունները կարող են նախաձեռնել եւ տվյալների հոսքը կարող է ցանկացած ուղղությամբ. Ագրեգացում ցույց է ունենալու ադամանդի նկատմամբ ամբողջ â € “”այս դեպքում, իհարկե, կազմել իհարկե զոհաբերություններով: Պատճառն այն այս ագրեգացման կլինի ասել, իմ ծրագրավորողներին, որ եթե նրանք ազատվել այս ընթացքում, նրանք հավանաբար պետք է անել ինչ – որ բան հատուկ է ընթացքը զոհաբերություններով: Կախվածությունը ցուցադրվում են որպես գծիկներով. Դա ասելով, որ գրանցումը կառավարիչը կախված է ժամանակացույցի Ալգորիթմ է անել ինչ – որ բան. Ժամանակացույցի Algorithm կամ մի պարամետր մեկի մեթոդների, կամ հայտարարվել է տեղական մեկի կողմից մեթոդիկայի գրանցման կառավարչի:
Բազմազանությունը եւ Navigation
Բազմազանությունը սահմանում, թե ինչպես բազմաթիվ օբյեկտներ մասնակցելու է հարաբերությունների. Դա այն թիվն ատյաններում մեկ դասի հետ կապված մեկ օրինակ է մյուս դասի. Յուրաքանչյուր ասոցիացիայի եւ ագրեգացման, կան երկու բազմազանությունը որոշումներ կատարելու `մեկը յուրաքանչյուր ավարտին հարաբերություններում. Բազմազանությունը ներկայացված է որպես մի շարք, եւ * օգտագործվում է ներկայացնում մի բազմազանությունը շատերը.
Նկար 12: բազմազանությունը եւ նավիգացիոն
One Պրոֆեսոր օբյեկտը կապված է զրոյական-ի չորս դասընթաց Առաջարկելով օբյեկտների. Մեկ Դասընթացի Առաջարկելով օբյեկտ կապված է ուղիղ մեկ պրոֆեսոր օբյեկտ: Ես օգտագործել այս նայում, եւ ապահովել, որ այս բռնակներ իմ պահանջները: Կարող եմ լինել դասընթաց տեղաբաշխում եւ պետք է թիմային ուսուցանվում է մի փունջ դասախոսների: Ոչ, քանի որ սա ասում եմ, կարող է ունենալ միայն մեկ դասախոս: Կարող եմ լինել պրոֆեսորի եւ պետք է sabbatical. Այո, քանի որ սա ասում ես ունեմ մի զրոն որպես հնարավոր իհարկե բեռը. Ես օգտագործել բազմազանությունը շատ հաճախ է օգնել ինձ սկսել capturing եւ իրականացման իմ բիզնես կանոնները: Եթե դուք ունեք, օրինակ, բիզնես կանոն, որը ասում է, որ դուք պետք է ունենա առնվազն 3 ուսանողներին եւ ոչ ավելի, քան 10 է, իհարկե պետք է առաջարկվում է կիսամյակի, այդ բազմազանությունը թվերը, ասեք ինձ, ես ներառված, որ բիզնես կանոն են այս ծրագրում:
Navigation է ցուցադրվում է նետը, ու թեեւ ասոցիացիաները եւ հանրագումար են Bi- Ուղղորդված ըստ նախնականի, դա հաճախ ցանկալի է սահմանափակել նավարկություն մեկ ուղղությամբ: Երբ Նավիգացիա սահմանափակված է, նետի ավելացված ցույց նավագնացական ուղղությունը: Մեկը այն բաները, որ ես անել ընթացքում վերլուծության եւ նախագծման փուլերի է նայենք, թե ինչ ես ցանկանում եմ լինել uni-Ուղղորդված. Դնելով սլաքը մեջ այս գծագիրը, ես ասում եմ, որ գրանցումը կառավարիչ կարող է հաղորդագրություն ուղարկել, իհարկե, քանի որ գիտի դասընթաց կա. Բայց այդ Դասընթացի գաղափար անգամ չունի, որ գրանցումը տնօրեն գոյություն ունի, այնպես որ, իհարկե չի կարող նախաձեռնել է հաղորդագրություն. Այժմ տվյալները կարող հոսում նրանց միջեւ. օրինակ Գրանցման կառավարիչ կարող է հարցնել, եթե իհարկե դա բաց է, եւ, իհարկե, կարող է ասել, որ դա այդպես է: Բայց միայն գրանցման կառավարիչ կարող է սկսվել այդ խոսակցությունը:
Ակնառու է, որ նպատակն այստեղ է ստանալ, քանի որ շատ Ռադիո, ինչպես դուք կարող եք այն ժամանակ, երբ ես ավարտեցի նախագծումը, քանի որ դա շատ ավելի հեշտ համակարգ է պահպանել ժառանգությունը ցուցադրվում է եռանկյունու. Սա ցույց է տալիս, որ պրոֆեսոր է գրանցումը, Օգտվող, քանի որ այն Ուսանողական. Այժմ, մի խոսք նախազգուշացման: Ժառանգաբար օգտակար է, սակայն, որ նպատակը ոչ թե պետք է օգտագործել, քանի որ շատ ժառանգութեան ձեր համակարգը թույլ կտա: Ես տեսել եմ մի քանի իսկապես դաժան համակարգեր, որտեղ իրենք ժառանգության 17 մակարդակներում խոր. Եթե նրանք փոխվել մեկ բան, այն դարձել է աղետի: Այնպես որ կանոնը thumb է օգտագործել ժառանգութիւն միայն այն ժամանակ, երբ դուք իսկապես ունեք իբրեւ ժառանգութիւն իրավիճակը.
Պետական Անցումային դիագրամների
Պետությունը անցումային դիագրամ ցույց է տալիս կյանքի պատմությունը տվյալ դասի: Այն ցույց է տալիս իրադարձությունները, որոնք առաջացնում անցում մեկ այլ պետություն, եւ այն գործողությունները, որոնք արդյունք պետական փոփոխության.
Գծապատկեր 14: State անցումը դիագրամ
Ես օգտագործել պետական անցումային դիագրամների օբյեկտի դասերի, որոնք, որպես կանոն, ունեն շատ դինամիկ վարքագծի. Կոճակը գտնվում է € | կոճակը անջատված է: Ես չեմ պատրաստվում անել պետական աղյուսակը դրա համար: Բայց object դասեր, որոնք ունեն շատ դինամիկ վարքագծի, ես, հավանաբար, պատրաստվում է նայենք դեպի երկրների օբյեկտների.
Ես սկսել է մի պետություն, որը կլորացված եռանկյունի. Ես կարող եմ ունենալ սկիզբը պետություններ, եւ ես կարող եմ ունենալ կանգառը պետություններ, որոնք ցուցադրվում են որպես Bulls աչքերով. Ես կարող եմ նաեւ ունենալ transitions միջեւ պետությունները, կամ զորքերի Տրանզիշնզ (բաներ, որ տեղի ունենա, երբ միայն, երբ մի պայման ճիշտ է), կամ բաներ, որ պատահել, երբ ես եմ ներսում պետություն: Ես նայում եմ այս դիագրամի եւ տեսնել, պետական անցումային դիագրամ է, իհարկե առաջարկի. Այն սկսվում է initialization վիճակում, եւ ես մնում եմ այդ վիճակում, մինչեւ ես ստանալ “”Ավելացնել ուսանող» հաղորդագրությունը: Երբ ես ստանալ այդ ուղերձը, ես իմ հաշիվը ուսանողի է զրոյի, եւ ես անցում կատարել բաց պետությանը: Դուք կտեսնեք Նկար 14 որ ես պետք է մուտք գործելու, եւ պատճառը, թե ինչու դա կա, որ ես ունեմ երկու ուղիներ ստանալու այդ պետության: Այն ասում է, որ անկախ նրանից, թե ինչպես եք ուժի մեջ պետության, ես ուզում եմ ձեզ գրանցել ուսանողին: Երբ ես exit այդ պետությունը, հաշվիչ փոփոխությունները չկորցնել թվի ուսանողների, իհարկե. Ես կարող եմ պահել, ավելացնելով ուսանողներին մինչեւ ես ստանում է 10, ապա կերթամ սերտ պետությանը: Երբ դասընթացը վերջնական տեսքի, ես անցում կատարել stop պետությանը: Անկախ նրանից, որտեղ ես եմ, ապա, եթե ես ստանալ դադարեցնել իրադարձությունը անցումը, ես այդ մասին իմ ուսանողներին սովորեցնել, այնուհետեւ անցում կատարել stop պետությանը:
Օբյեկտի դասերի, որոնք ունեն շատ դինամիկ վարքագծի, դա լավ արժե դա անել պետական դիագրաման է ստանալ բռնակի վրա ամեն ինչ, որ պետք է տեղի ունենա: Հարցրեք ինքներդ ձեզ, թե ինչ է տեղի ունենում, երբ ես ստանում է հաղորդագրություն. Ինչ կարող եմ անել, երբ ես կստանաք հաղորդագրություն: Ինչ պատգամներ է, ես պետք է ուղարկել. Շատ այդ ուղերձներից է դառնալ գործողությունները օբյեկտի դասի, քանի որ այս օրինակում, որտեղ ավելացնել ուսանողը գործողությունը: Շատ այդ գործողությունների, նման ստեղծման հաշվարկը, incrementing հաշվարկը, ստուգելով հաշվարկը, սրանք բոլորն են դառնալ մասնավոր գործողությունները տվյալ օբյեկտի դասի եւ պետական դիագրամ է, որտեղ ես տեսնում եմ, որ.
Ինչպես դուք գիտեք, եթե դուք ունեք մի դինամիկ օբյեկտ դաս. Կրկին, վերադառնալ հաջորդականությունը դիագրամների. Եթե դուք ունեք որեւէ օբյեկտ դաս, որ դա մի շատ հաջորդականությունը դիագրամների եւ դա ստանալու եւ ուղարկելու շատ հաղորդագրություններից, դա լավ նշան, որ դա բավականին դինամիկ օբյեկտ դասի, եւ այն պետք է, հավանաբար, պետք է պետական աղյուսակը դրա համար: Նաեւ aggregations, որտեղ դուք ունեք ամբողջ իր մասերի, ես պետական աղյուսակը յուրաքանչյուր համախառն ամբողջություն. Ես դա անել հիմնականում, քանի որ համախառն ամբողջ շատ հաճախ պատասխանատու է կառավարման հաղորդագրությունների, ինչը դինամիկ:
Component դիագրամների
Իհարկե ոչ մի համակարգ չի կարող լինել կառուցվել առանց հաշվի առնելու, որ ֆիզիկական աշխարհը: Ահա թե որտեղ բաղադրիչ դիագրամների գալիս: Նրանք օգտագործվում են ցույց կազմակերպություններին եւ կախվածությունը շրջանում ծրագրային բաղադրիչների, այդ թվում `կոդով բաղադրիչների, առաջադրվելու ժամանակ բաղադրիչներ կամ որպես executable բաղադրիչի: Բաղադրիչները ցույց է տալիս, որպես մի մեծ ուղղանկյան երկու փոքր ուղղանկյուններ կողմում, ինչպես երեւում է Գծապատկեր 15:
Նկար 15: Components
Այդ կլոր բաներ ներկայացնում ինտերֆեյս (հաճախ կոչվում Lollipop նշում): Այս դեպքում, նրանք ցույց են տալիս, որ Register.exe կախված է ինտերֆեյսերի այնպես էլ Course.dll եւ People.dll: Դա նշանակում է, որ եթե այդ ինտերֆեյս փոխվի, ապա դա կլինի ազդել Register.exe: Ես գիտեմ, որ կա այս կանոնը, երբ դուք ցանկանում եք կառուցել ինտերֆեյս, որ ասում է, «Դու չպետք է փոխել միջերեսի»: Բայց որեւէ մեկը, ըստ էության, աշխատել, որտեղ, որ կանոնը ուժի մեջ է մտել: Այս դիագրամ պատմում է մեզ, թե ինչ ինտերֆեյս օգտագործվում են, թե ինչ կատարելիները են վազում իմ պրոցեսորների:
Գծապատկեր 16: տեղակայումը դիագրամ
երկարաձգելու UML
Վերջին բանը, որ ես ուզում եմ շեշտել, այն մասին, UML է, որ այն կարող է երկարաձգվել: Երբ նրանք կառուցել են UML, նրանք շատ իմաստուն ձեւով հասկացա, որ չկար ոչ մի կերպ նրանք կարող են ստեղծել նշում է, որ կարող է, խնդրում է բոլոր այն մարդկանց, ամբողջ ժամանակ. Այնպես որ, նրանք մեզ տվել հայեցակարգը կարծրատիպը: Կարծրատիպը, – ասում է, ես կարող եմ վերցնել հիմնական մոդելավորման տարր եւ տալ այն ավելի իմաստ. Կարծրատիպերը կարող է օգտագործվել դասակարգելու եւ ընդլայնել ասոցիացիաներ, Ժառանգություն հարաբերություններ, դասեր, եւ բաղադրիչներ.
Գծապատկեր 17: Վեբ կարծրատիպ օրինակը
Գծապատկեր 17 ցույց է տալիս դիագրաման մեր վեբ կարծրատիպերի: A Web էջ սովորաբար ունի իրերը, որ աշխատում է սերվերից եւ կազմի, որ աշխատում է հաճախորդի. Եթե դուք ցանկանում եք կառուցել վեբ վրա հիմնված դիմումները, թե ինչ է վազում է հաճախորդի եւ սերվերի ունի կենսական նշանակություն: Այնպես որ, մենք ունենք մի ամբողջ շարք կարծրատիպերի, որոնք ցույց են տալիս, որ. Փոքրիկ-կոնտ, Ալյում.հեծ ներկայացնում բաներ, որոնք վարում է սերվերի. Այնպես որ, պարզապես նայելով այս մեկ սխեմայում Ես տեսնում եմ, թե ինչ ասված է սերվերի վրա, թե ինչ աշխատում է հաճախորդի, եւ այն, ինչ բիզնես օբյեկտների նրանք պետք է զբաղվել:

“——————————————————————————————————————————————————

Support tərcümə: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”UML ifadə görselleştirilmesi, tikintisi və proqram sisteminin bütün artefakt sənədləşdirilməsi üçün standart dilidir.””
Fəaliyyət şemalar
UML diaqramları bəzi vasitəsilə gəzinti başlamaq üçün məntiqi yer fəaliyyət diaqramları baxaraq deyil.
Şəkil 2: Fəaliyyət diaqram
Fəaliyyət diaqramları nəzarət axını göstərir. Şəkil 2-də göstərildiyi kimi, dairəvi düzbucaqlı kimi təmsil fəaliyyəti bilərsiniz. € “”hərəkətin ardından növbəti dövlət avtomatik keçid tam ki, â Activities adətən fəaliyyət dövlətlərdir. dairə dolu bir fəaliyyət diaqram start təmsil € “”harada nəzarət başlayır axını. Siz fəaliyyəti fəaliyyətinə hərəkət necə oxlar kimi göstərilir Transitions göstərir. fəaliyyət paralel olaraq baş necə Sinxronizasiya barlar göstərir. Mən “”Mən bu vəziyyəti doğru yalnız bu getmək istəyirəm”” deyir ki, bir keçid qorumaq bilər və dayanır harada sizə göstərmək olar. Müəyyən bir yaş əgər İndi, yəqin ki, bu aktivlik Diaqram baxmaq lazımdır və hesab edirəm ki, â € “”Hmm |. bir axını chart kimi görünür”” Və mən proqramlaşdırma səviyyədə aşağı bunu deyiləm istisna olmaqla, nə dəqiq var. Adətən, mən iş iş göstərmək mənim təhlili və dizayn prosesi kifayət qədər erkən bir fəaliyyət diaqram istifadə edin. Mən də istifadə halları hər baş nə istifadə halda göstərmək üçün bir fəaliyyət ola bilər göstərmək üçün istifadə edəcəyik. Mən də hər şeyi mənim istifadə halları arasında axını necə göstərmək üçün fəaliyyət diaqramları istifadə edin.
Amma UML haqqında böyük şeyi biri onun çox yönlü deyil. Mən yaşam dövrü əvvəlində fəaliyyəti diaqramları istifadə edərkən Belə ki, başqaları tamamilə fərqli bir mərhələsində istifadə edə bilərsiniz. Mən fəaliyyəti müəyyən bir sinfi üçün alqoritmlərin çox mürəkkəb set idi dizayn səviyyədə aşağı diaqramları istifadə gördüm. Və bir çox insanlar sinif üsulları arasında axını göstərmək üçün istifadə edirlər.
sistemi. Aktyorlar stick rəqəmlər kimi təmsil olunur.
Şəkil 4: Aktyorlar
Mən UML bu tətbiqi üçün tərtib nümunə bir kurs qeydiyyat sistemi bir az model. Mənim analiz prosesi xahiş edir başlayan zaman bu halda Belə ki, ilk şey edəcəyini “”Kim bu sistemi ilə qarşılıqlı gedir?””
Əlbəttə qeydiyyat model üçün, mən bir Qeydiyyatçı, professor və tələbə var. Mən də xarici göndərmə sistemi var. Bu faturalandırma sistemi də aktyor kimi xarakterizə. (Aktyor sistemi ilə qarşılıqlı lakin sisteminin xaricində € “”bir şey bir şəxs olmaq deyil, baxın.)
A istifadə halda bir informasiya sistemi bir aktyor tərəfindən həyata keçirilir əlaqədar əməliyyatların ardıcıllıqla deyil. Və ya, İngilis qoymaq üçün, bir istifadə halda funksionallıq bir yığın edir. Və burada əsas var: bu bir proqram modulu deyil € “”bu aktyor dəyər təmin şeydir.
Istifadə halları oval kimi göstərilir və onları tapmaq üçün en asan yol aktyorlar hər baxmaq və onlar sistemi istifadə etmək istədiyiniz nə özünüz xahiş edir. Mənim halda, mənim qeydiyyatdan mənim tələbə cədvəli saxlayır, mənim professor bir siyahısı tələb edir, tədris saxlamaq gedir və mənim faturalandırma sistemi göndərmə məlumat alır. Mən baxımından müştəri baxımdan baxaraq və xahiş mənim istifadə halları yaratmaq “”, belə ki, cənab sistemi aktyor, niyə sistemi istifadə etmək istəyirsiniz? Nə dəyəri bu sistem sizə təmin edir?””
Sizin aktyorlar sistemi ilə qarşılıqlı olacaq necə müəyyən sonra, növbəti addım, sizin istifadə halları sənəd yoxdur. Hər istifadə halda hadisələrin axını ilə sənədləşdirilmiş olmalıdır, və bu fikir aktyor baxımından edilir. istifadə halda icra zaman ətraflı sistem aktyor təmin etməlidir nə. Adətən bu istifadə halda başlayır və başa necə kimi şeylər göstərəcək. Nə şeyi istifadə halda nə var? Siz hər şey işləyir (I “”xoşbəxt günləri”” ssenari zəng nə) hadisələr normal axını, lazımdır. Sonra hadisələr anormal axını “”yağışlı gün”” ssenari almaq lazımdır. Sistem işləmir ne olur? Mən həmişə xoşbəxt günlər ssenari ilə başlamaq hadisələr mənim axını sənədləşdirir gördük.
avtomatlaşdırılmış teller maşın gəzinti, nümunə kimi edin. Siz ATM qədər gəzmək və kart daxil edin. Bu PİN sayı üçün xahiş edir. Siz daxil edin və siz nə etmək istəyirəm nə tələb olunur. Siz “”Mən bəzi pul istəyirəm.”” Deyə Bu pul alınmalıdır harada soruşur. Siz yoxlanılması hesabı onu demək. Bu nə qədər soruşur. Siz $ 100.00 deyirlər. bu $ 100.00 verir | € â Sonra sehrli olur. Başqa bir əməliyyat istəyirsinizsə Sonra soruşur. Siz demək. Bu geri kart verir qəbz verir və əməliyyat bitdi. Ki, xoşbəxt gün ssenari var.
Second ssenari. Siz ATM qədər getmək, kart daxil edin və PİN daxil edin. ATM yanlış PİN var deyir. Siz yenə nömrənizi daxil edin. Yenə PIN yanlış olduğunu bildirib. Siz mənim kurs qeydiyyat Məsələn, məsələn, “”X onda Y”” axınları bir çox var ki, görə bilərsiniz. sizə yardım etmək üçün müştəri istəyirəm harada. Əldə müqavilə erkən müştəri bu ssenariləri anlayır və deyir deməkdir “”bəli, bu, istədiyiniz nə deyil.”” Onlar aktyorlar, istifadə halları və onların arasında əlaqələri göstərmək çünki istifadə hallarda, nə tikinti edirik müştəri istəyir nə həqiqətən təmin etmək üçün böyük yoldur.
Şəkil 5: hal diaqram istifadə
Beləliklə, biz qrafik mənə nə göstərir ki, bir böyük diaqram var? cavab sisteminin yaxşı bir ümumi göstərir ki, bir böyük diagram edir “”sadə â edir €. Bu sistemi (aktyor) və sistem (istifadə halları) təqdim etməlidir funksionallığı xaricində nə göstərir. Siz nəzərə almaq lazımdır ki, bir miras sistemi varsa siz ilə məşğul olduğu, burada. interfeys bu cür ilə işləmək üçün məni məcbur çox erkən layihə Mən dəyişə bilməz ki, qara qutu danışmaq üçün gedirəm necə anlamaq üçün başlayır kodlaşdırma qədər gözləmə perspektivi ilə qarşı-qarşıya deyil o deməkdir ki .
Siz istifadə halları haqqında bilmək lazımdır bir şey daha istifadə halda həyata keçirilməsidir. Bu, “”necə”” istifadə haldır. ardıcıllıqla diaqramları, əməkdaşlıq diaqramlar və biz iştirak dərsləri bir görünüşü zəng sinif diagram: Bu adətən diaqramlar üç müxtəlif növ olan bir bucket var. İstifadə işi reallaşmağa əsasən birlikdə istifadə halda dizayn ilə bağlı əsərlər bir sıra qruplaşdırılması bir yoldur.
Sequence şemalar
Sequence diaqramları bir dəfə ardıcıllıqla təşkil obyekt qarşılıqlı göstərir. Hadisələrin axını ilə müəyyən funksionallığı yerinə yetirmək lazımdır nə obyektlərin və qarşılıqlı mən müəyyən etmək üçün tədbirlər axını istifadə edə bilərsiniz.
Şəkil 6: Sequence diaqram
Şəkil 6 tələbə uğurla kurs əlavə edilir necə göstərir. tələbə Bəzi məlumatlara doldurur və formada təqdim (Joe ona zəng edək). form sonra meneceri danışır və “”Math 101. Joe əlavə et”” deyir meneceri bir tələbə əlavə var Math 101 deyir. Math 101 “”açmaq var?”” Bölmə 1 deyir Math 101 bu tələbə əlavə etmək üçün bölmə 1 deyir ki, bu halda, Bölmə 1 cavab onlar açıq olduğunu. Onlar sizin və müştəri addım-addım baş nə göstərir, çünki Yenə sequence diaqramlardan böyük tools əvvəlində var.
baxımından təhlili baxımdan, mən ardıcıllıqla diaqramları me tələbləri idarə yardım çox güclü il ərzində gördük; tapmaq çətindir, xüsusilə tələblər. Siz həmişə yalnız testable deyil tələblərinə almaq üçün görünür, çünki User interface tələblər, məsələn, bədnam edir. Bu kimi bir ümumi UI tələb “”Bu sistem istifadəçi dostu olmalıdır”” dir. Necə bir çox bir dost kompüter görüşüb? diaqramları bu cür faydaları biri bir şəxs təmsil bir aktyor gələn hər line, siz həmin şəxs tərəfindən lazım olan bir qabiliyyətini təmin etmək üçün var ki UI bir şey deyir ki. Başqa sözlə, siz testable istifadəçi interfeysi tələbləri çəkmək üçün ardıcıllıqla diaqramları istifadə edə bilərsiniz.
Sequence diaqramlar, buna görə də, tələbləri yol və müştərilər ilə iş, neler göstərmək üçün yaxşı. Bu adətən yaratmaq lazımdır necə çox olsa da, sual gətirib çıxarır? “”Əgər kifayət qədər nə qədər.”” Mənim cavab var Siz, hər hansı bir yeni obyektlərin tapmaq heç bir yeni mesajlar tapmaq deyil olduğunuz bir nöqtəyə çatmaq sequence diaqramlardan zaman tapmaq olacaq, və üzərində eyni şey yazaraq etdiyiniz. Joe Math 101 qoşulması Məsələn, biz, Joe Belə tarixi 101. thumb qayda qoşulmaq istəyirdi proses eyni olacağını öyrənmək hər istifadə halda hər əsas axını üçün bir sequence diagram yoxdur. yüksək səviyyədə, riskli ssenariləri üçün bir sequence diagram, və ki, kifayət qədər olmalıdır. Mən necə çox ardıcıllıqla diaqramları var.
Burada xatırlamaq, bir əməkdaşlıq diagram bir ssenari yalnız bir fərqli və ən yaxşı point göstərir görünüşü almaq üçün sequence sxemlərinin və əməkdaşlıq diaqramlardan arasında geri və irəli getmək bilər.
Bəzən, siz söz “”qarşılıqlı diaqramları.”” Eşitmək bilər Bəzən insanlar kollektiv əməkdaşlıq diagram və qarşılıqlı diagram bir sequence diagram müraciət edəcək.
Class şemalar
A sinifi ümumi strukturu, ümumi davranış, ümumi münasibətləri və ümumi semantika ilə obyektlərin toplusudur. Siz sequence və əməkdaşlıq diaqramlardan obyektlərin araşdıraraq onları tapmaq və onlar üç compartments ilə bir düzbucaqlı kimi UML təmsil olunur.
Şəkil 8: Dərslər
ilk yuvası ikinci strukturu (atributları) göstərir, sinif adı göstərilir, üçüncü öz davranışı (əməliyyatlar) göstərir. Yalnız adı, yalnız adı və atributları, və ya bütün üç edə bilərsiniz ki, bu compartments, lakin yatırıldı bilər. siz də bilməlidir bir şey domen söz istifadə və standart seçin, dərsləri adlandırma zaman, vacibdir ki. Bu halda, mənim siniflər kapital məktubu ilə başlayan bütün sinqulyar isim var. Siz fərqli bunu seçə bilər, və ki, fərqi yoxdur. Nə məsələ yoxdur layihə əvvəl standart seçin və hər şey layihə üzrə ardıcıl ki, onunla qalmaq edir.
Class şemalar sizin sisteminin statik təbiət göstərir. Bu diaqramları dərsləri bir sistemin məntiqi baxımından onların münasibətlərin mövcudluğunu göstərir. Siz model bir çox sinif diaqramları var.
sinif diaqramları tapıldı UML modelləşdirmə elementləri daxildir:
Dərslər və onların strukturu və davranış.
Association, aqreqasiya, asılılıq və miras münasibətlər.
Multiplicity və naviqasiya göstəriciləri
Rolu adları.
Bu diaqram əməliyyatlar (davranış) göstərir Şəkil 9. bir göz atın: sinif bir obyekt nə edə bilər. Mən qarşılıqlı diaqramları baxaraq mənim əməliyyatları tapa bilərsiniz.
Şəkil 9: Operations
Burada mən Math bir tələbə əlavə etmək üçün qeydiyyat meneceri xahiş etmək lazımdır ki, dedi alıram
adlı əməliyyatda tərcümə olacaq 101. “”addCourse””.
Bir sinif strukturu onun atributları ilə təmsil olunur. Belə ki, necə Mən atributları tapa bilərəm? domain ekspertlər danışaraq. Mənim tələblər baxaraq. Mənim Məsələn, mən hər kurs təklif bir sıra, bir yer, və bir vaxt var ki, məlumat. Bu üç atributları həyata çevirir.
dərsləri. (Bütün təmsil sinif yanında bir almaz ilə əlaqədar dərsləri birləşdirən xətt kimi UML təmsil.)
€ ¢ â asılılıq â € “”a zəif forması müştəri və müştəri təchizatçı semantik bilik yoxdur təchizatçı arasında əlaqələr göstərilir. A asılılıq “”Mən sizin xidmətləri lazımdır, amma siz mövcud bilmirəm.”” Deyir (Təchizatçı üçün müştəri işarə berbat xətt kimi UML təmsil.)
əlaqələri tapmaq üçün, bir daha, Mən sequence diagram geri. iki obyektləri “”danışmaq”” üçün ehtiyac varsa, bir vasitə bunu olmalıdır (yəni, onların siniflər arasında əlaqələr).
Mən adətən həyata başlamaq və hər şey bir dərnək etmək. Mən daha analiz edirəm ki, Mən bir valideyn-uşaq münasibətlərinin qayğı üçün gedirəm, çünki mən bir toplama var tapa bilərsiniz. Mən dizayn mərhələsinə almaq zaman, mən başqası € â mənim metodları “”mən bir asılılıq etmək birinə obyekt keçmək gedir, çünki mən bir dərnək lazım deyil ki, tapa bilərsiniz.
Şəkil 11: münasibətlər
Şəkil 11 siz bu əlaqələri oldu. Dərnək olaraq Professor Prof danışmaq olar Course təklif və Tədris Təklif danışmaq olar deyir. Mesajlar başlana bilər və məlumat hər hansı bir istiqamətdə daxil edə bilərsiniz. Ümumiləşdirmə bir Kurs kurs qurbanları ibarətdir, bu halda “”bütün â € doğru almaz edərək göstərilir. bu toplama səbəbi bu Kursu xilas, onlar yəqin ki, kurs qurbanları ilə xüsusi bir şey etmək lazımdır ki, mənim developers demək olardı. Dependencies bir berbat xətt kimi göstərilir. Bu qeydiyyat meneceri şey etmək Schedule alqoritmi asılıdır olduğunu söyləyən oldu. Schedule alqoritmi üsullardan biri üçün bir parametri ya və ya Qeydiyyat Manager üsullardan biri ilə yerli elan edilir.
Multiplicity və Naviqasiya
Multiplicity çox obyektlərin əlaqələr iştirak necə müəyyən edir. Digər sinif bir misal ilə bağlı bir sinif hallarda sayı. əlaqələr hər sonuna biri hər dərnək və toplama üçün etmək üçün iki çoxluğu qərarlar var. Multiplicity bir sıra təmsil olunur və a * çox çoxsaylı təmsil etmək üçün istifadə olunur.
Şəkil 12: Multiplicity və naviqasiya
One Professor Object sıfır-to-dörd Course təklif obyektləri ilə bağlıdır. Obyekt təklif One Course dəqiq bir Professor Obyekt ilə bağlıdır. Mən baxmaq və bu mənim tələblərinə emal təmin etmək üçün bu istifadə edin. Mən kursu təklif ola bilər və professor bir dəstə ilə komanda-tədris olunacaq? Xeyr, bu yalnız bir professor ola bilər deyir, çünki. Mən professor və məzuniyyətləri ola bilər? bu deyir, çünki Bəli, mən mümkün kurs yük kimi bir sıfır var. Mən almasına və mənim iş qaydaları həyata başlamaq kömək etmək üçün kifayət qədər tez-tez çoxsaylı istifadə edin. Əgər, misal üçün, ən azı 3 şagird və bir kurs üçün artıq 10 dövr təklif olmalıdır deyir ki, bir iş qayda bu çoxluğu ədəd bu plan biznes qayda ki, daxil etdik mənə.
Naviqasiya ox göstərilir və dərnək və aggregations bi-yönlü default baxmayaraq, tez-tez bir istiqamətdə üçün naviqasiya məhdudlaşdırmaq olardı. naviqasiya məhdud zaman, bir arrowhead naviqasiya istiqaməti göstərir əlavə edilir. təhlili və dizayn mərhələlərində Mən şeylərdən biri I uni-yönlü olmaq istəyirəm nə baxmaq edir. Bu diaqram daxil arrow qoyaraq, mən əlbəttə mövcuddur bilir, çünki Qeydiyyat Manager, Kursu bir mesaj göndərə bilərsiniz ki. Amma əlbəttə Qeydiyyat Manager var ki, heç bir fikir var, belə ki, Course bir mesaj başlamaq bilməz. İndi data onların arasında axını bilər; məsələn açıq əgər Qeydiyyat Manager Kursu xahiş edə bilər və Course Bu demək olar ki. Ancaq Qeydiyyat Manager söhbət başlaya bilərsiniz.
Aydındır ki, burada məqsəd bir üçbucaq ilə göstərilir ölən şəxsin qorumaq üçün çox asandır sistemi, çünki zaman siz, dizayn başa sonra kimi bir çox oxlar almaq üçün. Bu tələbə kimi Professor, bir qeydiyyat User olduğunu göstərir. İndi xəbərdarlıq bir söz. Miras Lakin, məqsədi sistem imkan verir qədər miras istifadə etmək deyil, faydalıdır. Mən dərin miras 17 səviyyələri var idi həqiqətən qəddar sistemləri gördüm. onlar bir şey dəyişib, bu, bir fəlakət oldu. Belə ki, thumb qayda siz həqiqətən bir miras vəziyyət var yalnız miras istifadə edir.
State Transition şemalar
Dövlət keçid diagram bir sinif həyat tarixi göstərir. Bu, bir dövlət başqa bir keçid səbəb hadisələr və dövlət dəyişiklik nəticəsində tədbirlər göstərir.
Şəkil 14: State keçid diaqram
Mən adətən dinamik davranış bir çox obyekt siniflər üçün dövlət keçid diaqramları istifadə edin. düyməsini € edir | düyməsini off; Mən bunun üçün dövlət chart etmək niyyətində deyiləm. Amma dinamik davranış bir çox obyekt dərsləri, mən yəqin ki, obyektlərin dövlətlərə baxmaq üçün gedirəm.
Mən dairəvi üçbucaq dövlət göstərən başlayın. Mən start dövlətlər ola bilər, və mən öküz göz kimi göstərilir stop dövlətlər, ola bilər. Mən də dövlətlərin, və ya gözətçi keçid (şərti doğru zaman yalnız baş şeyi), və ya dövlət daxilində olduğumu baş şeylər arasında keçid edə bilərsiniz. Mən bu diaqram baxmaq və kurs təklif dövlət keçid diaqram bax. Bu başlatma dövlət başlayır və mən bir “”tələbə əlavə et”” mesajı almaq qədər ki, dövlət qalmaq. Hesab edirəm ki, mesaj almaq zaman, mən sıfıra tələbə mənim count və mən Open dövlət keçid. Siz Şəkil Mən giriş var 14 görürsünüz və bu, var səbəbi Hesab edirəm ki, dövlət əldə iki yolu var. Bu, heç bir məsələ dövlət gəlmək necə, mən tələbə qeydiyyatdan istəyirəm ki, deyir. Hesab edirəm ki, dövlət çıxmaq zaman, count dəyişikliklər zamanı tələbələrin sayı takip. Mən 10 almaq qədər tələbə əlavə edə bilərsiniz, və sonra yaxın dövlət gedin. Əlbəttə başa sonra, mən stop dövlət keçid. Mən Ləğv Hadisə keçid almaq əgər, Mən tələbə xəbər və sonra stop dövlət keçid, sonra am olursa olsun.
dinamik davranış bir çox obyekt dərsləri, bu baş hər şey bir qolu almaq üçün dövlət diaqram etmək yaxşı dəyər. Mən bir mesaj almaq zaman nə özünüz soruşun? Mən mesajı almaq zaman mən nə etməliyəm? I Nə mesaj göndərmək üçün var? həmin mesajların bir çox tələbə bir əməliyyat əlavə bu misal kimi, obyekt sinif əməliyyatları olur. Bu tədbirlər bir çox, sayı qəbulu sayı incrementing, sayı yoxlanılması kimi, bu bütün xüsusi obyekt sinif xüsusi əməliyyatlar olmaq və mən ki, görəcəksiniz harada bir dövlət diagram edir.
Bir dinamik obyekt sinif var, əgər necə bilirsən? Bir daha, sequence diaqramlardan geri. Siz sequence diaqramlardan bir çox var bir obyekt sinif var və bu almaq və mesaj bir çox göndərilməsi varsa, ki, kifayət qədər dinamik obyekt sinif bir yaxşı göstəricisidir və yəqin ki, bunun üçün dövlət chart olmalıdır. Həmçinin onun hissələrinin bütün var aggregations üçün, mən hər məcmu bütün üçün dövlət chart yoxdur. ki, ümumi bütün dinamik edir mesajlaşma, idarə olunması üçün tez-tez məsuliyyət daşıyır, çünki mən əsasən bunu.
Komponent diaqramları
Əlbəttə heç bir sistem nəzərə fiziki dünya alınmadan inşa edilə bilər. Bu komponent diaqramları gəlib. Onlar mənbə kodu komponentləri, run dəfə komponentləri və ya çalıştırılabilir komponenti, o cümlədən, proqram təminatı komponentləri arasında təşkilatları və bağımlılıkları göstərmək üçün istifadə olunur var. Şəkil 15 göründüyü kimi Components, tərəfində iki kiçik düzbucaqlı ilə böyük düzbucaqlı kimi göstərir.
Şəkil 15: Components
Həmin dəyirmi şeylər interfeys (tez-tez adlanır lollipop notation) təmsil edir. Bu halda, onlar Register.exe Course.dll və People.dll həm interfeys asılı olduğunu göstərir. Yəni bu interfeys dəyişdirmək əgər, bu Register.exe təsir edəcək deməkdir. Mən deyir interfeys bina etdiyiniz bu qayda var ki, bilirik “”sən interface dəyişdirmək bilməz.”” ki, qayda tətbiq olunur, amma heç kimə həqiqətən işləyir? Bu diaqram nə executables mənim prosessorları çalışan istifadə olunur nə interfeys bizə deyir.
Şəkil 16: Deployment diaqram
UML genişləndirilməsi
Mən UML haqqında qeyd etmək istəyirəm son şey uzadıla bilər. Onlar UML inşa zaman, onlar çox ağıllı, onlar zaman bütün insanların bütün xahiş edirik ki, bir notation yarada bilər heç bir yol var idi ki, həyata keçirilir. Belə ki, onlar bizə stereotip anlayışını verdi. A stereotip bir əsas modelləşdirmə element almaq və daha çox məna verə bilər. Stereotiplər təsnif və birliklər, vərəsəlik əlaqələr, dərsləri, və komponentləri uzatmaq üçün istifadə edilə bilər.
Şəkil 17: Web stereotip nümunə
Şəkil 17 Web stereotiplərin diaqram göstərir. A Web səhifə adətən müştəri çalışır server və məhsulları çalışır stuff var. Web-based applications tikinti edirsinizsə, nə müştəri çalışan və server həyati əhəmiyyət kəsb edir. Beləliklə, biz göstərir ki, stereotipləri bütün dəsti var. az disklər server run şeyi təmsil edir. Belə ki, yalnız mən server çalışır nə edə bilərsiniz Bu bir diaqram baxaraq, nə müştəri çalışır və nə iş obyektlərin onlar ilə məşğul olmalıdır.

“——————————————————————————————————————————————————

Itzulpengintza euskarria: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”UML du, zehaztuz ikusgarrian, eraikitzeko, eta software sistema baten objektu guztiak dokumentatzeko hizkuntza estandarra da.””
Jarduera Diagramak
leku logikoa UML diagramak batzuk paseoan hasteko jarduera diagramak bilatzen da.
2. irudia: Activity diagram
Jarduera diagramak kontrol-fluxua erakusteko. 2. irudian ikus daitekeen bezala, laukizuzenak biribilduko gisa irudikatzen jarduera ikusi ahal izango duzu. Jarduerak dira normalean ekintza estatu â € “”estatu trantsizioa automatikoki hurrengo egoera ekintza ondoren osatu dela. The zirkulu bete Diagramarik hasieratik adierazten â € “”non kontrola hasten emaria. geziak bezala erakutsiko Transitions erakusteko nola jardueratik jarduera mugitu duzu. Sinkronizazioa tabernak erakusteko nola jarduera paralelo ere gertatuko. trantsizio bat dela dio zaintzen dut ahal “”behar duzu jarduera hau baldintza egia bada bakarrik joan nahi dut””, eta azaldu ahal izango dut non gelditzen. Orain Oraindik adin jakin bat bada, baliteke zuk Diagramarik hau begiratu eta pentsatzen, “”hmm â € |. Fluxuaren diagrama baten itxura du”” Eta hori zehazki zer da, salbu eta ez dut egiten behera programazio mailan. Normalean, jarduera-diagrama bat erabili dut nahiko goiz nire analisi eta diseinu-prozesuan enpresa workflow erakusteko. Ere erabili dut horiek non nire erabilera kasu bakoitzaren liteke jarduera bat izan zer erabilera kasuan gertatuko ditu ilustratzeko erakusteko. Ere erabiltzen dut jarduera diagramak nire erabilera kasu arteko gauzak nola osotasunean erakusteko.
Baina UML buruzko gauza handia bat bere malgutasuna da. Beraz, jarduera diagramak erabili nuen bitartean ziklo hasieran, beste batzuk erabili ahal ezberdinak fase batean oso-osorik. Ikusi dut jendeak erabiltzeko jarduera diagrama behera diseinu mailan non algoritmoak multzoa oso zaila klase jakin bat izan dute. Eta jende asko erabiltzen klase baten metodoen arteko fluxua erakusteko.
sistema. Aktoreak makila zifrak gisa irudikatzen dira.
4. irudia: Aktoreak
Adibide hori gora aritu nintzen Sarrera hau UML den ikastaro erregistro-sistema baten eredua apur bat da. Beraz, kasu honetan, lehenik eta behin, nire analisi prozesua da, eskatu hasita egin nahi nuke “”nor da sistema hau elkarreragin joan?””
Ikastaroa Izena emateko eredu baterako, erregistratzaile bat, irakasle bat, eta ikasle bat izan nuen. halaber, kanpoko fakturazio sistema bat daukat. fakturazio sistema honek, gainera, aktore gisa trebatzen. (Ikus, aktorea ez dute pertsona bat a € “”ezer egin hori sisteman elkarreraginean baina sistemaren kanpo da izan.)
erabilera-kasuen A aktore batek egiten sisteman elkarrizketa batean erlazionatutako transakzio sekuentzia bat da. Edo, Ingelesa, erabilera-kasuen batean funtzionalitate zatia da. Eta hemen da gakoa: ez da software modulu bat € “”duten balioa ematen aktorearen zerbait da.
kasu Erabili obaloak gisa agertzen dira, eta modurik errazena aurkitu da zure aktoreak bakoitzean begiratu eta galdetu zeure buruari, zergatik ez, sistema erabili nahi dute. Nire kasuan, nire erregistratzailea da curriculum eusteko doa, nire irakaslea da zerrendari bat eskatu du, nire ikaslearen ordutegia mantentzen du, eta nire fakturazio sistema fakturazio informazioa jasotzen. Beraz, nire erabilera kasu sortu dut bezeroaren ikuspegitik batetik begiratzeko eta, galdetuz “”, beraz, mister sistema aktore, zergatik ez sistema erabili nahi duzula? Zer balio du sistema hau duzu ematea?””
Hurrengo pausoa, zuk identifikatu behin nola zure aktoreak izango sistemarekin elkarreraginean izango da zure erabilera kasuak dokumentatzeko do. Erabilera Kasu bakoitza gertakari fluxua dokumentatu behar da, eta hau da aktore horrek ikuspuntu batetik egin. It behar zehatz-mehatz zer sistema aktoreari eman behar erabileraren kasuan abian dagoenean. Normalean erabilera kasuan nola hasten eta bukatzen bezalako gauzak erakutsiko ditu. Zer gauzak erabilera kasu horretan ez dute egin? gertakari fluxua normal (zer “”zoriontsu egun”” eszenatoki deitu dut), non dena lan egin duzu. Ondoren anormal ekitaldiak emaria, eta “”egun euritsu”” eszenatoki jasoko duzu. Zer gertatzen da, sistemak ez du funtzionatzen? Nire erabiltzen dut beti zoriontsu egun eszenatoki batera hasteko ekitaldiak emaria dokumentatzeko aurkitu dut.
adibide gisa Hartu, eman ibiltzeko makina bat da. oinez ATM, eta zure txartela sartu. Galdetzen zure PIN zenbakia da. Bertan sartuko zara, eta zer egin nahi duzun galdetuko zaizu. Esaten duzu “”dirua batzuk egin nahi dut.”” non dirua hartu behar dira galdetzen da. Kontatzeko duzu Hartuko den zure kontu egiaztapena. zenbat galdetzen da. $ 100.00 diozu. Ondoren, magia gertatzen â € | ematen du $ 100.00. Ondoren nahi duzun beste transakzio bada galdetzen da. ez diozu. zure txartela ematen du atzera, agiri bat ematen dizu, eta transakzio amaitu egingo da. Hori happy day eszenatoki izan.
Bigarren kasua. gora joan ATM duzu, zure txartela, eta sartu PINa. ATM esaten dizu PIN okerra da. Zure zenbakia sartuko zara berriro. Berriz esaten PIN hori ez da zuzena. Zu nire ikastaroan izena Adibidez, adibidez, ikusiko duzu ez dagoela “”X bada orduan Y”” fluxuak asko daude. Hori da, non nahi duzu zure bezeroak laguntzeko prest daude. Getting hasierako akordioa esan nahi zure bezero eszenatoki horiek ulertzen eta dio “”bai, hau da guk nahi duguna.”” kasu Erabili modu handi bat zer eraikitzen ari da, pena bezeroak zer nahi duen ziurtatzeko, aktoreak, erabilera kasuetan, eta horien arteko harremanak erakusten dutelako.
5. irudia: Erabili kasu diagram
Beraz, diagrama handia duten grafikoki erakusten dit zer egin behar dugu? Erantzuna oso sinplea da € “”diagram handi bat sistemaren ikuspegi ona erakusten duten da. zer sistema (aktoreak) eta funtzionalitate hori sisteman (erabilera kasu) eman behar da kanpo erakusten ditu. ez bada ondarea sistema bat kontuan hartu behar da, hemen non aurre egiten duzun. interfaces mota hauekin lan me behartzea oso goiz proiektua ere esan nahi dut, ezin izango da hasten kodifikazioa arte zain perspectiva aurrean irudikatu nola ez naiz kutxa beltz hori ezin dut aldatu ere hitz egin .
Gauza bat gehiago erabilera kasu buruz jakin behar duzu erabilera kasu gauzatzeko da. Hau da, “”nola”” erabilera horren adibideak. Ohi da hiru diagrama motak ezberdinak biltzen dituen ontzi bat: sekuentzia diagrama, lankidetza diagrama, eta klase diagrama batean klaseak parte hartzen duten ikuspegi bat deitzen dugun hori. Erabili kasuan realizations dira funtsean kasuan erabilera bat diseinatzeko lotutako artifacts zenbaki bat elkartzearen modu bat.
Sekuentzia-diagramak
Sekuentzia diagramak denbora sekuentzia bat antolatu objektu elkarrekintzak erakusteko. gertakari fluxua erabili ahal izango dut zehazteko zer objektu eta elkarrekintzak ekitaldiak fluxua zehazten dituen funtzionalitate betetzeko behar izango dut.
6. irudia: Sekuentzia-diagrama
6 grafikoak erakusten du ikasle bat arrakastaz lortzen ikastaro bat gehitu. Ikasleak (dezagun Joe deitzen zion) informazio batzuk ere betetzen eta inprimakia aurkeztu. Inprimakia ondoren kudeatzailea hitzaldiak eta dio “”gehitu Joe Math 101. izateko”” manager kontatzen Math 101 ikasle bat gehitzeko duela. Math 101 1.ataleko dio “”dira ireki duzu?”” Kasu honetan, 1. atala Erantzun hori zabalik dira, beraz Math 101 kontatzen 1 atala ikaslea hau gehitzeko. Berriz ere, sekuentzia diagramak tresna handia dira, hasiera batean zuk eta zure bezeroak erakutsiko dute urrats-urrats zer gertatuko duelako.
analisi ikuspegitik begiratuta, urteetan zehar izan dut aurkitu sekuentzia diagramak oso indartsua baldintzak gidatzeko me lagunduz dira; batez ere, eskakizun hori gogorra aurkitu. Erabiltzaile interfazea baldintzak, esate baterako, nabaria zabiltza hori besterik ez dira probako baldintzak iritsi delako. komun UI hau bezalako baldintza bat da “”Sistema honen erabiltzaileak errespetatzen izanen da.”” Nola asko ezagutu dituzte errespetatzen ordenagailu bat? diagrama motak horien onura bat da, lerro bakoitzean aktore bat duten pertsona bat adierazten datozen, zerbait zure UI ditu beharrezko pertsona horrek gaitasuna ematen hasi esaten dizu. Beste era batera esanda, sekuentzia diagramak erabili ahal izango duzu gidatzeko probako erabiltzaile interfazearen baldintzak.
Sekuentzia diagramak dira, beraz, zer ari den gertatzen, gidatzeko baldintzak, eta bezeroekin lan egiteko erakusten ona. Hori normalean galdera dakar, nahiz eta, zenbat Nola sortu behar duzu? Nire erantzuna da, “”nahikoa egin arte.”” jakiteko denean ez duzu sekuentzia diagramak duten puntu bat iritsiko non ez zaren edozein objektu berriak aurkitzeko, ez du mezu aurkitzeko ari zara, eta gauza bera egin eta gehiagoko idazten ari zaren. Joe Math 101 batu adibidea, prozesu hori bera izango litzateke Joe Historia 101. Beraz, arau batu nahi izanez sekuentzia diagrama bat egin erabilera kasu guztietan oinarrizko fluxua bakoitzean dagoen ikasiko dugu. Sekuentzia goi-mailako, arriskutsua agertoki dagoen diagrama bat, eta hori nahikoa izan beharko luke. Hau da, zenbat sekuentzia diagramak egin dut.
hemen gogoratu behar da, lankidetza-diagrama bat dela eszenatoki bat ikuspegi ezberdinak bat besterik ez da eta atzera eta aurrera joan ahal izango duzu sekuentzia diagramak eta lankidetza diagramak arteko ikuspegi Zure point hobekien erakusten duten lortzeko.
Batzuetan, esaldi “”elkarrekintza diagramak.”” Entzun dezakezu Batzuetan jendea taldeka egingo lankidetza diagrama bat eta sekuentzia diagrama baten elkarrekintza-diagrama gisa aipatzeko.
klase Diagramak
Klase A egitura komun, portaera, harremanak komunak, eta semantika berdinak dituzten objektuen bilduma bat da. Horietako aurkituko duzu sekuentzia eta lankidetza diagramak objektuak aztertuz, eta dute UML hiru ataleko laukizuzen gisa adierazten dira.
8. irudia: Klaseak
lehen konpartimenduan class izena erakusten, bigarren erakusten bere egitura (atributuak), eta hirugarrena, berriz, bere jokabidea (eragiketak) erakusten. konpartimentu horiek erreprimitu egin daiteke, ordea, eta, beraz, izena, besterik izena eta atributuak, edo hiru ikusi ahal izango duzu. Gauza bat ere jakin behar da garrantzitsua dela, noiz klaseak izendatzeko, domeinu hiztegia erabili eta estandar bat hautatzeko. Kasu honetan, nire klaseak nouns singular guztiak maiuskulaz hasten diren. Bestela egin ahal izango duzu, eta horrek ez du axola. Axola da zure proiektuaren aurretik estandar bat jaso duzu, eta jarraitu, beraz, dena da proiektuan zehar koherentea.
Klase Diagramak erakusten duzu zure sistemaren izaera estatikoa. Diagrama horiek klaseak eta bere sistema baten ikuspegi logikoak ere harremanak daudela erakusten dute. askok klase eredu batean diagramak aukera izango duzu.
klase diagramak aurki UML modelatze elementuek:
Klaseak eta haien egitura eta portaera.
Elkarteak, agregazio, mendekotasuna, eta herentzia harremanak.
Anizkortasuna eta nabigazio-adierazleak
Rol izenak.
Hartu 9. irudian begirada bat Diagrama honek erakusten eragiketak (portaera): zer klase horretan objektu bat egin dezake. Nire eragiketak aurkitu dut nire interakzio diagramak begira.
9. irudia: ebakuntzak
Hemen esaten dut izen-ematea kudeatzailea galdetzeko ikasle bat gehitzeko Math gai izan behar dut
101. Hori behar izeneko operazio batean itzuli joan “”addCourse.””
Klase baten egitura bere atributuak irudikatzen dute. Beraz, nola ez, nire atributuak aurkitu dut? domeinu adituek hitz eginez. nire eskakizunei begira. Nire adibidez, ikastaro eskaintza bakoitzean, zenbaki bat, kokapena, eta denbora dauka ikasiko dut. Hau itzultzen hiru atributu bat.
klaseak. (UML ordezkatuta lerro bat diamante bat klase osoari ordezkari ondoan, erlazionatutako klaseak konektatzen bezala.)
€ ¢ â € â Dependency “”forma ahulagoa bezero eta hornitzaile bat non bezeroak ez hornitzaile ezagutza semantikoa dute arteko erlazioa erakutsiz. mendekotasun batek “”zure zerbitzuak behar dut, baina ez dakit existitzen dela.”” (UML lerro bat, hornitzaile, bezero batetik seinalatuz bezala ordezkatuta.)
harremanak aurkitzeko, berriro ere, atzera egin dut nire sekuentzia diagramak. bi objektuei “”hitz egin”” behar bada, ez dago bide bat egin behar izan (hau da, bere klase arteko erlazioa).
normalean hasten dut eta dena elkarte bat egiteko. Azterketa egiten ari naiz bezala, agian agregazio bat daukat naiz zaindu guraso-haur harreman baten izan delako aurkitu dut. Noiz lortu diseinu fasean sartu nintzen, jakin nuen ez liteke elkarte bat behar beste norbait da objektu hori gainditzeko nire metodoak â € “”orain egin da mendekotasun bat dut bat sartu delako.
11. irudia: Harremanak
11 irudia Harreman horiek ikusten duzu. elkarte bezala dio katedradun ikastaro eskaintza, eta ikastaro eskaintza hitz egin dezake irakaslea hitz egin dezake. Mezuak abiarazi daiteke eta datuak edozein norabidetan osotasunean. Agregazioa du â € osoa lortze diamante izatea “”Kasu honetan ikastaro bat da ikastaro eskaintza osatua erakutsi. agregazio Horren arrazoia nire sustatzaileei kontatzeko ezagutu dute ikastaro hau kentzeko bada, seguruenik egingo dute zerbait ikastaro eskaintza batera bereziak egin ahal izango litzateke. Menpekotasunak lerro gisa agertzen dira. Honez erregistroa kudeatzailea Ordutegiak Algorithm mende dago zerbait egin behar esaten. Ordutegiak algoritmoa bai metodo bat den parametro bat da, edo lokalean deklaratu da emateen kudeatzailearen Metodoak bat arabera.
Anizkortasuna eta Itsasketa
Anizkortasuna definitzen du nola objektu batzuk erlazio batean parte hartzeko. Beste klase instantzia lotutako klase baten instantzia kopurua da. harreman amaieran bakoitzeko bat: elkarte eta agregazio bakoitzeko, bi askotarikotasun erabakiei egin badira. Anizkortasuna zenbaki bat bezala irudikatzen da eta * a askok anitz irudikatzeko erabiltzen da.
12. irudia: anizkortasuna eta nabigazioa
One irakaslea Object zero-lau ikastaro eskaini Objects lotuta dago. Ikastaroa One Object eskainiz zehazki irakaslea Object erlazioa dauka. hau erabiltzen dut begiratu, eta ziurtatu hori nire eskakizunak maneiatzen. Ezin ikastaro eskaintza bat izan nuen, eta talde-irakatsi irakaslek mordo batek? Ez, hau dio dudalako bakarrik izan daiteke irakasle bat. Ezin irakasle bat izan nuen eta urte sabatikoa izan? Bai, hau dio delako zero bat posible ikastaro karga gisa daukat. askotarikotasun erabiltzen dut sarritan atzemateko eta nire negozio-arauak ezartzeko hasteko me laguntzeko. badaukazu, adibidez, negozio arau bat dela dio, gutxienez 3 ikasle eta 10 ez-ikastaro bat baino gehiago seihileko bat eskaini izan behar duzu, aniztasuna zenbaki horiek esan dit nik gehituko ditudan araua enpresa plan hau sartu dela.
Itsasketa gezi baten bidez adierazten da, eta nahiz eta elkarte eta aggregations bi norabide lehenetsita daude, izaten da desiragarria nabigazioa mugatzeko norabide bat. Noiz nabigazioa mugatuta dago, gezi baten gehitu da nabigazio norabidea adierazteko. Gauzak ez dut analisi eta diseinua faseetan bat da zer uni norabide izan nahi dut begiratu. gezi jarriz diagrama honetan sartu, emateen kudeatzailearen mezu bat bidali ahal izango dute ikastaroan, badaki ikastaro existitzen delako esaten dut. Baina ikastaro no idea emateen kudeatzailearen badagoela ditu, beraz, ikastaro ezin mezu bat hastea. Orain datu horien arteko osotasunean; adibidez emateen kudeatzailearen ikastaro eskatu ahal irekia da, bada, eta ikastaro esan ahal izango da hori. Baina bakarrik emateen kudeatzailearen elkarrizketa hori hasteko dezakezu.
Jakina helburua da hemen geziak asko lortu ahal izango duzu, denbora amaitu duzu diseinatzeko bezala, sistema askoz errazagoa Inheritance eusteko triangelu bat erakusten delako. Honek erakusten irakaslea Izen ematea Erabiltzaile bat da, ikaslea da eta. Orain, abisu hitz bat. Oinordetza erabilgarria da, ordea, helburua ez da askoz ere herentzia gisa zure sistema izango baimendu erabili. batzuk sistemak benetan bortitza non herentzia 17-mailak izan zuten sakona ikusi dut. Gauza bat aldatu badute, hondamendi bat bihurtu da. Beraz, arau da herentzia erabili denean bakarrik benetan egin duzun herentzia egoeran izan.
Estatuko Trantsizio Diagramak
egoera trantsizio diagrama bizitza klase jakin baten historia azaltzen. trantsizio bat eragiten duten egoera batetik bestera gertaerak, eta hori egoera-aldaketa baten ondorioz ekintzak erakusten ditu.
14. irudia: Estatuko trantsizio-diagrama
egoera trantsizio diagramak erabiltzen dut normalean portaera dinamikoa asko izan objektu klase da. botoiak â € on da | botoia itzali da; Ez dut egoera taula bat egin da joan. Baina hori portaera dinamikoa asko izan objektu klaseak, Ziurrenik dut objektu estatuetan begiratu behar da.
hasteko egoera bat, eta horrek biribildu triangelu bat da erakutsiz dut. Irteeran estatu izan ahal dut, eta stop estatutan, zezenak begiak gisa ageri dira izan ahal dut. I ere izan dezake, estatu, edo guardia trantsizioak (gertatuko denean bakarrik baldintza bat egia da gauza), edo gertatuko naiz egoera barruan dut gauzak arteko trantsizioak. begiratu diagrama honetan egin nuen eta ikusi trantsizio egoera ikastaro eskaintza bat diagraman. hasten hasieratze egoera da, eta lo egoera horretan dut “”, gehitu ikaslea”” mezua agertzen zait arte. Mezu hori lortu dut, nire ikaslea kondea ezarri dut zero eta trantsizio Open egoerara dut. Figura 14 sarrera bat dut ikusteko aukera izango duzu, eta zergatik ez da da bi egoera hori iristeko biderik behar dudala. ez du axola nola etortzen egoera sartu duzu, ikaslearen izena eman behar duzu nahi dut esaten da. Noiz irteteko dut egoera hori, kopuruan aldaketak ikastaroa ikasleen kopurua segimendua egiteko. ikasleek gehituz lortu dut 10 arte mantendu ahal izango dut, eta, ondoren, joan zen Close egoerara dut. Ikastaroa bukatu ondoren, trantsizio stop egoera nahi dut. Ez dio axola non nagoen gero, bertan behera Gertaera trantsizioa lortu badut, nire ikasle jakinaraziko nuen eta, ondoren, geldialdia egoera trantsizioa.
duten portaera dinamikoa asko izan objektu klase lortzeko, ondo merezi du egoera-diagrama bat dela gertatuko dena helduleku bat lortzeko egin. Galdetu zeure buruari zer gertatuko den mezu bat jasoko dut? Zer egin behar dut mezua jasoko dut? Zer mezu I bidali dute? Mezu horiek asko dira objektu klasearen eragiketak, adibidez hau gehitu ikasle batek operazio bat da gisa. Ekintza horiek asko, Aldaketa ezartzeko, Aldaketa Incrementing, Aldaketa egiaztapena bezala, horiek guztiak bihurtzen diren objektu klase bereziko jarduerak pribatua eta egoera-diagrama bat da, non ikusten dudan.
Nola ez duzu objektu klase dinamiko bat izanez gero, jakin? Berriro ere, atzera sekuentzia diagramak izateko. objektu klase bat sekuentzia diagramak asko egin behar baduzu eta nik lortzean eta mezu asko bidaltzen, hori adierazle ona objektu klase nahiko dinamiko bat da, eta ziurrenik egoera taula bat izan behar da horretarako. Era aggregations, non bere zati osoa duzu, egoera osoa agregatua bakoitzean dagoen diagrama bat egin dut. hau egiten dut, batez ere, oro har, agregatua dela sarritan mezularitza, eta horrek dinamikoa kudeatzeko ardura delako.
Osagai diagramak
Jakina sistema ez da kontuan mundu fisikoa hartu gabe eraiki daiteke. Hori da, non osagai diagramak etortzen hasi. Software osagaiak artean erakunde eta mendekotasunen ilustratzeko, iturri kodea osagaiak, exekutatu denbora osagaiak, edo osagai exekutagarria barne erabiltzen dira. Osagaiak ikuskizunak aldean bi laukizuzenak txikiagoa laukizuzen handi bat bezala dira, ikusi 15. irudian ikusten den bezala.
15 Irudia: Osagaiak
Kopako gauzak dutenek interfazeak (sarritan piruleta notazioa) adierazten. Kasu honetan, Register.exe hori bai Course.dll eta People.dll du interfaces menpe erakutsiko dute. Horrek esan nahi du interfaces horiek aldatu bada, Register.exe eragina izango da. ez dagoela arau hori noiz ari interfazeak eraikitzeko duzu dioen ezagutzen dut «Ez dezu interfazea aldatzeko.”” Baina ez du inor benetan lan non arau hori behartuta dago? Diagrama honek esaten digu zer interfazeak erabiltzen dira zer by exekutagarriak dira nire prozesadoreak exekutatzen.
16. irudia: Inplementazio-diagrama
luzatzea UML
Azken gauza UML buruzko azpimarratu nahi dut dela luzatu daiteke. Noiz UML eraiki zuten, oso zentzuzkoa konturatu dira han zela jende guztia jar lezake denbora guztia notazio bat sortu zuten inola ere ez. Beraz estereotipo bat kontzeptua eman digute. estereotipo batek dioenez, oinarrizko modelaketa elementu bat hartu ahal izango dut eta eman esanahia gehiago. Estereotipoak erabili ahal izango dira sailkatzeko eta elkarteek, herentzia harremanak, klaseak, eta osagai zabaltzeko.
17. irudia: Web estereotipo adibidez
17. irudia gure web-estereotipoak diagraman erakusten ditu. Web orri bat normalean gauzak zerbitzaria eta horrelako gauzak bezeroa exekutatzen exekutatzen ditu. zu Web oinarritutako aplikazioak eraikitzeko bada, zer ari bezero eta exekutatzen zerbitzariak ezinbesteko garrantzia du. Beraz, erakutsi duten estereotipoak multzo oso bat izango dugu. gurpil txikia adierazten gauzak zerbitzariak exekutatzen dira. Beraz, bakar-diagrama honek zer zerbitzarian exekutatzen ikusiko dut begira, zer bezeroaren bidez, eta zer enpresa objektuak landu behar dute.

“——————————————————————————————————————————————————

пераклад Падтрымка: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”Мова UML з’яўляецца стандартнай мовай для вызначэння, візуалізацыі, канструявання і дакументавання ўсіх артэфактаў праграмнай сістэмы.””
актыўнасць Дыяграмы
Лагічнае месца, каб пачаць хадзіць праз некаторыя з UML-дыяграм, гледзячы на дыяграмы дзейнасці.
Малюнак 2: Дыяграма актыўнасці
Дыяграмы дзейнасці паказваюць паток кіравання. Як паказана на малюнку 2, вы можаце ўбачыць дзеяньне, прадстаўленыя ў выглядзе прастакутнікаў са скругленымі кутамі. Дзейнасць дзяржавы, як правіла, дзеянні â € “”заяўляе, што пераход аўтаматычна да наступнага стане пасля завяршэння дзеяння. Запоўнены круг ўяўляе сабой пачатак дыяграмы актыўнасці â € “”, дзе паток кантроль пачынаецца. Пераходы, паказаныя стрэлкамі паказана, як пры пераходзе ад дзейнасці да дзейнасці. бары сінхранізацыі паказваюць, як мерапрыемствы ажыццяўляюцца паралельна. Я магу абараніць пераход, які кажа: “”Я хачу, каб ты на гэтую дзейнасць, толькі калі гэта ўмова праўдзіва,”” і я магу паказаць вам, дзе ён спыняецца. Цяпер, калі вы пэўнага ўзросту, вы, верагодна, паглядзіце на гэтую дыяграму дзейнасці і думаю, “”Хмм â € |, які выглядае як блок-схемы.”” І гэта менавіта тое, што гэта, за выключэннем таго, што я не раблю гэта ўніз на ўзроўні праграмавання. Як правіла, я выкарыстоўваю дыяграму дзейнасці даволі рана ў маім аналізе і працэсу праектавання, каб паказаць бізнес-працэс. Я таксама буду выкарыстоўваць іх, каб паказаць, дзе кожны з маіх выпадкаў выкарыстання можа быць у дзейнасці, каб праілюстраваць, што выпадак выкарыстання павінна адбыцца. Я таксама выкарыстоўваю дыяграмы дзейнасці, каб паказаць, як усё цячэ паміж маімі прэцэдэнтамі.
Але адна з вялікіх рэчаў аб UML з’яўляецца яго ўніверсальнасць. Такім чынам, у той час як я выкарыстоўваю дыяграмы дзейнасці ў пачатку жыццёвага цыкла, а іншыя могуць выкарыстоўваць іх у іншы фазе цалкам. Я бачыў, як людзі выкарыстоўваюць дыяграмы актыўнасці ўніз на ўзроўні праектавання, дзе яны мелі вельмі складаны набор алгарытмаў для канкрэтнага класа. І многія людзі выкарыстоўваюць іх, каб паказаць паток паміж метадамі класа.
сістэма. Акцёры прадстаўлены як палкі лічбы.
Малюнак 4: Акцёры
Прыклад, які я працаваў для гэтага ўвядзення ў UML трохі мадэль сістэмы рэгістрацыі курса. Такім чынам, у дадзеным выпадку, першае, што я хацеў бы зрабіць пры запуску майго працэсу аналізу спытаць, “”хто збіраецца ўзаемадзейнічаць з гэтай сістэмай?””
Для мадэлі рэгістрацыі вядома, у мяне ёсць рэгістратар, прафесар і студэнт. У мяне таксама ёсць знешні білінгавую сістэму. Гэтая плацежная сістэма таксама кваліфікуецца як акцёр. (Глядзі, акцёр не павінен быць чалавек, â € “”, гэта ўсё, што ўзаемадзейнічае з сістэмай, але знаходзіцца па-за межамі сістэмы.)
Прэцэдэнт ўяўляе сабой паслядоўнасць узаемазвязаных пагадненняў, якія здзяйсняюцца акцёрам у сістэме ў дыялогавым акне. Ці, кажучы на англійскай мове, выпадак выкарыстання з’яўляецца кавалак функцыянальнасці. І вось ключ: гэта не модуль праграмнае забеспячэнне € “”гэта тое, што забяспечвае каштоўнасць для акцёра.
Прэцэдэнты прадстаўлены ў выглядзе авалаў, і самы просты спосаб, каб знайсці іх, каб глядзець на кожны з вашых акцёраў і спытаеце сябе, чаму яны хочуць, каб выкарыстоўваць гэтую сістэму. У маім выпадку, мой рэгістратар будзе падтрымліваць навучальны план, мой прафесар збіраецца запытаць спіс, мой вучань падтрымлівае расклад, і мая плацежная сістэма атрымлівае аплатную інфармацыю. Так што я ствараю свае варыянты выкарыстання, гледзячы на яго з пункту гледжання кліента і спытаць “”, таму, сістэма спадар акцёр, чаму вы хочаце выкарыстоўваць сістэму? Якое значэнне мае гэтая сістэма забяспечыць вам?””
Наступным крокам пасля таго, як вы вызначылі, як вашыя акцёры будуць ўзаемадзейнічаць з сістэмай, ці з’яўляецца дакументаваць выпадкі выкарыстання. Кожны выпадак выкарыстання павінен быць дакументаваны з патокам падзей, і гэта робіцца з пункту акцёра гледжання. Яна павінна падрабязна апісаць тое, што сістэма павінна даць акцёру, калі выпадак выкарыстання выконваецца. Як правіла, ён будзе паказваць такія рэчы, як, як варыянт выкарыстання пачынаецца і заканчваецца. Якія рэчы робіць, што выпадак выкарыстання павінен рабіць? Вы будзеце мець нармальны паток падзей (тое, што я называю сцэнар «шчаслівыя дні»), дзе ўсё працуе. Тады вы атрымаеце анамальны паток падзей, сцэнар «чорны дзень». Што адбываецца, калі сістэма не працуе? Я знайшоў, дакументальна мой паток падзей, якія я заўсёды пачынаю з дзён сцэнара шчаслівым.
Возьмем у якасці прыкладу, падыходзячы да банкамата. Вы падыходзіце да банкамата і ўставіць карту. Ён запытвае нумар вашай PIN-кода. Вы ўводзіце яго, і вас спытаюць, што вы хацелі б зрабіць. Вы кажаце: “”Я хачу, каб нейкія грошы.”” Ён пытаецца, дзе грошы павінны быць ўзятыя з. Вы кажаце гэта, каб узяць яго з вашага разліковага рахунку. Яна пытае, колькі. Вы кажаце, што $ 100,00. Тады чараўніцтва адбываецца â € | гэта дае вам $ 100,00. Затым ён пытаецца, калі вы хочаце іншую здзелку. Вы не кажаце няма. Гэта дае вам карту, выдае вам квітанцыю, і здзелка скончаная. Гэта шчаслівы дзень сцэнар.
Другі сцэнар. Вы ідзяце да банкамата, ўставіць карту, і ўвядзіце свой PIN-код. Банкамат кажа вам, што няправільны PIN-код. Вы ўводзіце свой нумар яшчэ раз. Зноў жа вы сказалі, што PIN-код з’яўляецца памылковым. Вы ў маім курсе прыклад рэгістрацыі, напрыклад, вы можаце бачыць, што ёсць шмат “”калі X, то ў”” працоўныя працэсы. Вось дзе вы хочаце, каб ваш кліент, каб дапамагчы вам. Атрыманне пагаднення ў пачатку азначае, што ваш кліент разумее гэтыя сцэнары і кажа: «Так, гэта тое, што мы хочам.”” Прэцэдэнты з’яўляюцца выдатным спосабам, каб пераканацца, што тое, што вы ствараеце на самой справе тое, што кліент хоча, таму што яны паказваюць акцёраў, выпадкі выкарыстання, і адносіны паміж імі.
Малюнак 5: Дыяграма прэцэдэнтаў
Такім чынам, у нас ёсць вялікая схема, якая графічна паказвае мне што? Адказ просты â € “”гэта вялікая дыяграма, якая паказвае добры агляд сістэмы. Гэта паказвае, што знаходзіцца па-за сістэмай (акцёры) і функцыянальныя магчымасці, якія сістэма павінна забяспечваць (выпадкі выкарыстання). Калі ёсць атрыманая ў спадчыну сістэма вы павінны прыняць да ўвагі, вось дзе вы маеце справу з ім. Прымушаючы мяне працаваць з гэтымі тыпамі інтэрфейсаў вельмі рана ў праекце азначае, што я не прыйдзецца сутыкнуцца з перспектывай чакання да кадавання пачынаецца, каб высветліць, як я буду гаварыць з гэтага чорнага скрыні, што я не магу змяніць ,
Яшчэ адна рэч, якую вы павінны ведаць пра выпадкі выкарыстання з’яўляецца рэалізацыя выпадак выкарыстання. Гэта “”як”” выкарыстанне кейс. Гэта, як правіла, вядро, якое змяшчае тры розных тыпу дыяграм: дыяграмы паслядоўнасці, дыяграмы супрацоўніцтва і дыяграмы класаў, якія мы называем ўяўленне ўдзельнічаюць класаў. Рэалізацыях прэцэдэнтаў у асноўным спосаб групоўкі разам шэраг артэфактаў, якія адносяцца да канструкцыі выпадкі выкарыстання.
дыяграмы паслядоўнасцяў
Дыяграмы паслядоўнасці паказваюць ўзаемадзеянне аб’ектаў, размешчаных у паслядоўнасці часу. Я магу выкарыстоўваць паток падзей, каб вызначыць, якія аб’екты і ўзаемадзеяння, мне трэба будзе выконваць функцыі, названага патоку падзей.
Малюнак 6: Дыяграма паслядоўнасці
На малюнку 6 паказана, як студэнт паспяхова дадаецца ў курс. Студэнт (назавем яго Джо) запаўняе некаторую інфармацыю і адпраўляе форму. Форма затым кажа мэнэджару і кажа: “”дадаць Джо Math 101.”” Менеджэр кажа Math 101, што ён павінен дадаць студэнта. Math 101 кажа, што ў раздзеле 1 “”вы адкрыты?”” У гэтым выпадку, частка 1 адказ, што яны адкрытыя, так што Math 101 кажа раздзел 1, каб дадаць гэты студэнт. Зноў жа, дыяграмы паслядоўнасці вялікія сродкі ў пачатку, таму што яны паказваюць, вы і ваш кліент крок за крокам, што павінна адбыцца.
З пункту аналізу гледжання, я знайшоў на працягу многіх гадоў, што дыяграмы паслядоўнасці з’яўляюцца вельмі магутнымі, дапамагаючы мне сесці за руль патрабаванні; асабліва патрабаванні, якія цяжка знайсці. Патрабаванні інтэрфейсу карыстальніка, напрыклад, сумна вядомыя, таму што вы заўсёды здаецца, каб атрымаць патрабаванні, якія проста не правяраецца. Агульным патрабаваннем UI, як гэта “”гэтая сістэма павінна быць зручнай.”” Колькі з вас сустрэў дружалюбны кампутар? Адным з пераваг гэтых тыпаў дыяграм з’яўляецца тое, што кожная лінія, якая выходзіць з акцёра, які ўяўляе чалавека, кажа вам, што нешта ў вашым UI павінен даць магчымасць, неабходную гэтаму чалавеку. Іншымі словамі, вы можаце выкарыстоўваць дыяграмы паслядоўнасці, каб выцесніць правяраныя патрабаванні карыстацкага інтэрфейсу.
Дыяграмы паслядоўнасці, такім чынам, добра паказвае, што адбываецца, для прывядзення ў рух з патрабаванняў, а таксама для працы з кліентамі. Гэта звычайна прыводзіць да пытання, хоць, колькі вам трэба стварыць? Мой адказ, “”пакуль вы не зробіце дастаткова.”” Вы збіраецеся высветліць, калі вы робіце дыяграмы паслядоўнасці, што вы дасягне кропкі, дзе вы не знойдзеце якіх-небудзь новых аб’ектаў, якія не знайшоўшы якіх-небудзь новых паведамленняў, і што вы друкуеце тое ж самае зноў і зноў. У прыкладзе Джо далучэння Math 101, мы даведаемся, што гэты працэс будзе такім жа, калі Джо хацеў далучыцца да гісторыі 101. Такім чынам, эмпірычнае правіла, зрабіць дыяграму паслядоўнасці для кожнага асноўнага патоку кожнага выпадку выкарыстання. Ёсць Дыяграма паслядоўнасці для высокага ўзроўню, рызыкоўных сцэнарыяў, і гэта павінна быць дастаткова. Вось колькі паслядоўнасць дыяграм я раблю.
ўспомніць тут, што Дыяграма кааперацыі гэта проста іншы від сцэнарыя, і вы можаце вярнуцца назад і наперад паміж дыяграмы паслядоўнасці і дыяграмы кааперацыі, каб атрымаць уяўленне, што лепш за ўсё ілюструе свой пункт гледжання.
Часам можна пачуць словазлучэнне «дыяграмы ўзаемадзеяння.”” Часам людзі ў сукупнасці ставяцца да дыяграме супрацоўніцтва і дыяграмы паслядоўнасці як дыяграмы ўзаемадзеяння.
дыяграмы класаў
Клас ўяўляе сабой сукупнасць аб’ектаў з агульнай структурай, агульнай паводзін, агульных адносін і агульных семантыкі. Вы знойдзеце іх, даследуючы аб’екты ў пэўнай паслядоўнасці і сумеснай працы дыяграм, і яны прадстаўлены ў UML ў выглядзе прамавугольніка з трыма аддзяленнямі.
Малюнак 8: Класы
Першае аддзяленне паказвае імя класа, другі паказвае яго структуру (атрыбуты), а трэці паказвае яго паводзіны (аперацыі). Гэтыя адсекі могуць быць падушаныя, аднак, так што вы можаце ўбачыць толькі імя, толькі імя і атрыбуты, ці ўсе тры. Адна рэч, якую вы таксама павінны ведаць, што гэта важна, калі наймення класаў, выкарыстоўваць слоўнікавы запас дамена і выбраць стандарт. Для гэтага, напрыклад, мае класы ўсе асаблівыя імёны, якія пачынаюцца з вялікай літары. Вы можаце выбраць, каб зрабіць гэта па-іншаму, і гэта не мае значэння. Што сапраўды мае значэнне ў тым, што да вашага праекта вы выбіраеце стандарт і прытрымлівацца яго, так што ўсё адпавядае ўсім праекце.
Дыяграмы класаў паказаць вам статычны характар вашай сістэмы. Гэтыя дыяграмы паказваюць наяўнасць класаў і іх узаемаадносін у лагічным выглядзе сістэмы. У вас будзе шмат дыяграм класаў у мадэлі.
Элементы UML мадэлявання знойдзены ў дыяграмах класаў ўключаюць у сябе:
Класы і іх структура і паводзіны.
Асацыяцыя, агрэгацыя, залежнасць, і адносіны ў спадчыну.
Кратнасць і навігацыйныя індыкатары
Імёны роляў.
Паглядзіце на малюнку 9. Гэтая дыяграма паказвае аперацыі (паводзіны): тое, што аб’ект у гэтым класе можа зрабіць. Я лічу, мае аперацыі, гледзячы на маіх узаемадзеянняў дыяграм.
Малюнак 9: Аперацыі
Вось я і кажу, што мне трэба, каб мець магчымасць звярнуцца да мэнэджэра рэгістрацыі дадаць студэнта Math
101. Гэта збіраецца перавесці ў аперацыі пад назвай “”addCourse.””
Структура класа прадстаўлена яго атрыбутамі. Так як жа знайсці свае атрыбуты? Размаўляючы з экспертамі ў прадметнай вобласці. Гледзячы на маё патрабаванне. У маім прыкладзе, я даведаўся, што кожны курс прапанову мае нумар, месцазнаходжанне і час. Гэта прыводзіць да трох атрыбутам.
класы. (Прадстаўлена ў UML ў выглядзе лініі, якая злучае адпаведныя класы з дыяментам побач з класам, якi прадстаўляе ўвесь.)
â € ¢ Залежнасць ад â € “”больш слабая форма, які паказвае суадносіны паміж кліентам і пастаўшчыком, дзе кліент не мае семантычных ведаў пастаўшчыка. Залежнасць кажа: “”Мне патрэбныя вашыя паслугі, але я не ведаю, што ты ёсць.”” (Прадстаўлена ў UML ў выглядзе пункцірнай лініі, паказваючы ад кліента да пастаўшчыка.)
Каб знайсці адносіны, яшчэ раз, я вяртаюся да маёй дыяграме паслядоўнасці. Калі два аб’екта павінны “”гаварыць””, павінна быць сродкам зрабіць гэта (гэта значыць, сувязь паміж іх класамі).
Я, як правіла, пачынаюць і зрабіць усё асацыяцыі. Як я раблю больш аналізу, я мог бы знайсці мяне агрэгацыю, таму што я буду мець, каб клапаціцца аб адносінах бацька-дзіця. Калі я ўваходжу ў стадыі распрацоўкі, я лічу, што я, магчыма, не патрэбна сувязь, таму што хто-то збіраецца перадаць гэты аб’ект у адзін з маіх метадаў â € “”, так што я зрабіць яго залежнасць.
Малюнак 11: Адносіны
На малюнку 11 вы бачыце гэтыя адносіны. Як асацыяцыі кажа прафесар можа весці размову з курсу ахвяраю, і прапанова курса можа пагаварыць з прафесарам. Паведамленні могуць быць ініцыяваныя і дадзеныя могуць паступаць з любога кірунку. Агрэгацыя паказаны пры наяўнасці алмаз да ўсяго â € “”у гэтым выпадку курс складаецца з Offerings курса. Прычынай такога аб’яднання павінен быў бы сказаць сваім распрацоўнікам, што калі яны пазбавіцца ад гэтага курса, яны, верагодна, прыйдзецца зрабіць нешта асаблівае з прапановамі курса. Залежнасці прадстаўленыя ў выглядзе пункцірнай лініі. Гэта сведчыць аб тым, што менеджэр па рэгістрацыі залежыць ад раскладу алгарытму зрабіць нешта. Расклад Алгарытм з’яўляецца альбо параметр для аднаго з метадаў або аб’яўляецца лакальна з дапамогай аднаго з метадаў рэгістрацыі дыспетчара.
Кратнасць і рух
Кратнасць вызначае, колькі аб’ектаў ўдзельнічаюць у адносінах. Гэта колькасць асобнікаў аднаго класа, звязаных з адным асобнікам іншага класа. Для кожнай асацыяцыі і агрэгацыі, існуе два множнасць рашэнняў, каб зрабіць: па адным для кожнага канца адносін. Кратнасць прадстаўляецца ў выглядзе шэрагу і * выкарыстоўваецца для абазначэння множнасці многіх.
Малюнак 12: Кратнасць і рух
Адзін прафесар Аб’ект звязаны з нуля да чатырох праспектаў курсу аб’ектаў. Адзін курс Прапаноўваючы аб’ект звязаны з роўна адзін прафесар Object. Я выкарыстоўваю гэта, каб паглядзець і пераканацца, што гэта апрацоўвае мае патрабаванні. Ці магу я быць якая прапануе курс і быць камандай-самавук звязкам прафесараў? Няма, таму што гэта кажа, што я магу мець толькі адзін прафесар. Ці магу я быць прафесарам і быць у творчым адпачынку? Так, таму што гэта кажа, што я нуль у якасці магчымай нагрузкі курсу. Я выкарыстоўваю мноства даволі часта, каб дапамагчы мне пачаць захоп і рэалізацыі сваіх бізнес-правілаў. Калі ў вас ёсць, напрыклад, бізнес-правіла, якое кажа, што вы павінны мець па крайняй меры 3 студэнтаў і не больш за 10 на працягу курсу, якія будуць прапанаваныя на працягу семестра, гэтыя лічбы кратнасці кажуць мне, што я уключаны, што бізнес-правілы ў гэтым плане.
Сістэма навігацыі паказана стрэлкай, і хоць асацыяцыі і агрэгавання з’яўляюцца двунакіраваную па змаўчанні, часта пажадана абмежаваць навігацыю па адным напрамку. Калі рух абмежаваная, наканечнік стралы дадаецца, каб паказаць навігацыйную кірунак. Адна з рэчаў, якія я раблю на этапах аналізу і праектавання, гэта паглядзець на тое, што я хачу быць аднанакіраваныя. Паставіўшы стрэлку ў гэтай дыяграме, я кажу, што Менеджэр па рэгістрацыі можа адправіць паведамленне на курс, таму што ён ведае, што курс існуе. Але курс не мае ні найменшага падання аб тым, што існуе Менеджэр па рэгістрацыі, таму курс не можа ініцыяваць паведамленне. Зараз дадзеныя могуць перадавацца паміж імі; напрыклад, рэгістрацыйная менеджэр можа папрасіць курс, калі ён адкрыты, і, вядома, можа сказаць, што гэта. Але толькі Менеджэр па рэгістрацыі можа пачаць гэтую размову.
Відавочна, што мэта тут, каб атрымаць як мага больш стрэл, як вы можаце да таго часу, як вы скончылі распрацоўку, таму што гэта значна прасцей сістэма для падтрымання ў спадчыну паказаны з трохвугольнікам. Гэта паказвае, што прафесар з’яўляецца рэгістрацыя карыстальніка, як гэта мае месца Student. Цяпер слова папярэджання. Ўспадкоўванне карысна, аднак, мэта складаецца ў тым, каб не выкарыстоўваць столькі спадчыну, як ваша сістэма дазволіць. Я бачыў некаторыя сапраўды жорсткія сістэмы, дзе яны мелі спадчыну 17 узроўняў у глыбіню. Калі яны змянілі адну рэч, гэта стала катастрофай. Такім чынам, правіла заключаецца ў тым, каб выкарыстоўваць спадчыну толькі тады, калі вы сапраўды сапраўды ёсць сітуацыю ў спадчыну.
Дзяржаўныя дыяграмы пераходаў
Дыяграма пераходу станаў паказвае гісторыю жыцця дадзенага класа. Гэта паказвае падзеі, якія выклікаюць пераход з аднаго стану ў іншы, а таксама дзеянні, якія з’яўляюцца вынікам змены стану.
Малюнак 14: Дыяграма станаў пераходу
Я выкарыстоўваю дыяграмы станаў пераходаў для класаў аб’ектаў, якія звычайна маюць шмат дынамічнага паводзін. Кнопка знаходзіцца на € | кнопка выключана; Я не збіраюся рабіць дзяржаўную схему для яго. Але класы аб’ектаў, якія маюць шмат дынамічнага паводзін, я, верагодна, прыйдзецца глядзець у стану аб’ектаў.
Я пачынаю, які паказвае стан, якое з’яўляецца круглявы трохкутнік. Я магу мець пачатковыя стану, і я магу мець стоп стану, якія паказаны як быкі вочы. Я таксама можа мець пераходы паміж станамі, або вартавых пераходамі (рэчы, якія адбываюцца, калі толькі тады, калі ўмова праўдзіва), або рэчы, якія адбываюцца, калі я знаходжуся ўнутры дзяржавы. Я гляджу на гэтую дыяграму і ўбачыць дыяграму стану пераходу для курсу акцый. Яна пачынаецца ў стане ініцыялізацыі, і я застануся ў такім стане, пакуль я атрымліваю паведамленне “”дадаць студэнт””. Калі я атрымліваю гэта паведамленне, я ўсталяваў мой рахунак студэнта да нуля, і я перайсці ў адкрытае стан. Вы ўбачыце на малюнку 14, што ў мяне ёсць запіс, і прычына, чаму гэта ёсьць тое, што ў мяне ёсць два спосабу атрымання ў гэты стан. Ён кажа, што незалежна ад таго, як вы прыйшлі ў стан, я не хачу, каб вы зарэгістраваць студэнта. Калі я выйсці з гэтага стану, змяняецца колькасць, каб сачыць за колькасцю студэнтаў у працэсе. Я магу працягваць дадаваць студэнтаў, пакуль я не да 10, а затым я іду ў закрытае стан. Пасля таго, як курс будзе завершаны, я перайсці ў стан прыпынку. Незалежна ад таго, дзе я тады, калі я атрымліваю Адмена падзеі пераходу, папярэджваю сваіх студэнтаў, а затым перайсці ў стан прыпынку.
Для класаў аб’ектаў, якія маюць шмат дынамічнага паводзін, гэта добра варта зрабіць дыяграму станаў, каб атрымаць ручку на ўсё, што павінна адбыцца. Спытаеце сябе, што адбываецца, калі я атрымліваю паведамленне? Што мне рабіць, калі я атрымліваю паведамленне? Якія паведамленні, каб я павінен паслаць? Многія з гэтых паведамленняў становяцца аперацыі класа аб’ектаў, як у гэтым прыкладзе, дзе дадаць студэнт з’яўляецца аперацыя. Многія з гэтых дзеянняў, як ўстаноўка лічыльніка, якія павялічваюцца лічыльнік, правяраючы іх колькасць, усе яны становяцца прыватныя аперацыі гэтага канкрэтнага класа аб’ектаў і дыяграма станаў, дзе я бачу, што.
Як вы ведаеце, калі ў вас ёсць дынамічны клас аб’ектаў? Яшчэ раз, вярніцеся да дыяграмы паслядоўнасці. Калі ў вас ёсць клас аб’ект, які на шмат дыяграм паслядоўнасцяў і гэта атрыманне і адпраўку шмат паведамленняў, што гэта добрая прыкмета таго, што гэта даволі дынамічны клас аб’екта, і ён павінен, верагодна, мець дзяржаўную дыяграму для яго. Акрамя таго, для вялікай колькасці, дзе ў вас ёсць уся яго частак, я дзяржаўную дыяграму для кожнага сукупнага цэлага. Я раблю гэта ў асноўным таму, што сукупнае цэлае часта адказвае за кіраванне паведамленнямі, што робіць яго дынамічным.
дыяграмы кампанентаў
Вядома, ні адна сістэма не можа быць пабудаваная без уліку фізічнага свету. Вось дзе Дыяграма кампанентаў ўваходзяць. Яны выкарыстоўваюцца для ілюстрацыі арганізацыі і залежнасцяў паміж праграмнымі кампанентамі, уключаючы кампаненты зыходнага кода, запускаць кампаненты часу, або выкананага кампанента. Кампаненты паказвае, як вялікі прастакутнік з двума меншымі прастакутнікамі на баку, як паказана на малюнку 15.
Малюнак 15: Кампаненты
Гэтыя круглыя рэчы ўяўляюць сабой інтэрфейсы (часта называюць лядзяш Notation). У гэтым выпадку, яны паказваюць, што Register.exe залежыць ад інтэрфейсаў як Course.dll і People.dll. Гэта азначае, што, калі гэтыя інтэрфейсы мяняюцца, гэта паўплывае на Register.exe. Я ведаю, што ёсць гэтае правіла, калі вы ствараеце інтэрфейс, які кажа “”ты не павінен мяняць інтэрфейс.”” Але хіба хто-небудзь на самай справе працуе, дзе гэта правіла выконваецца? Гэтая дыяграма кажа нам, якія інтэрфейсы выкарыстоўваюцца, якія праграмы працуюць на сваіх працэсарах.
Малюнак 16: Схема разгортвання
пашырэнне UML
Апошняе, што я хацеў бы падкрэсліць, аб UML з’яўляецца тое, што ён можа быць прадоўжаны. Калі яны пабудавалі UML, яны вельмі мудра зразумелі, што не было ніякага спосабу, яны маглі б стварыць абазначэння, якія маглі б пацешыць усіх людзей увесь час. Такім чынам, яны далі нам паняцце стэрэатыпу. Стэрэатып кажа, што я магу ўзяць базавы элемент мадэлявання і надаць яму большае значэнне. Стэрэатыпы могуць быць выкарыстаны для класіфікацыі і пашырыць асацыяцыі, адносіны ў спадчыну, класы і кампаненты.
Малюнак 17: Вэб-прыклад стэрэатыпу
На малюнку 17 паказана схема нашых вэб-стэрэатыпаў. Вэб-старонка, як правіла, мае матэрыял, які працуе на сэрвэры і матэрыял, які працуе на кліенцкім кампутары. Калі вы ствараеце вэб-прыкладанні, што працуе на кліенце і сервер мае жыццёва важнае значэнне. Такім чынам, у нас ёсць цэлы набор стэрэатыпаў, якія паказваюць, што. Маленькія колы ўяўляюць сабой рэчы, якія працуюць на серверы. Так што, проста гледзячы на гэтай адной дыяграме я магу ўбачыць, што працуе на серверы, тое, што працуе на кліенце, і якія бізнес-аб’екты, ім даводзіцца мець справу з.

“——————————————————————————————————————————————————

সাপোর্ট অনুবাদ: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”ইউএমএল, উল্লেখ না visualizing, নির্মাণ, এবং একটি সফ্টওয়্যার সিস্টেম সব হস্তনির্মিত দলিল জন্য প্রমিত ভাষা.””
চাঞ্চল্যপূর্ণ রেখাচিত্র
যৌক্তিক জায়গা ইউএমএল ডায়াগ্রামে কিছু মাধ্যমে হাঁটা শুরু কার্যকলাপ ডায়াগ্রামে এ খুঁজছেন দ্বারা হয়.
চিত্র 2: চাঞ্চল্যপূর্ণ ডায়াগ্রাম
চাঞ্চল্যপূর্ণ ডায়াগ্রামে নিয়ন্ত্রণ প্রবাহ দেন. চিত্র 2 সচিত্র, আপনি বৃত্তাকার আয়তক্ষেত্র হিসাবে প্রতিনিধিত্ব কার্যক্রম দেখতে পারেন. ক্রিয়াকলাপ সাধারণত কর্ম রাজ্যের € “”যুক্তরাষ্ট্রের পরবর্তী অবস্থায় রূপান্তর স্বয়ংক্রিয়ভাবে কর্ম পর সম্পূর্ণ যে হয়. বৃত্তে ভরা একটি কার্যকলাপ ডায়াগ্রাম শুরুর প্রতিনিধিত্ব € “”যেখানে নিয়ন্ত্রণ শুরু প্রবাহ. তীর হিসাবে দেখানো ট্রানজিশন আপনাকে কিভাবে কার্যকলাপ থেকে কার্যকলাপ সরাতে. সুংসগতি বার দেন কিভাবে কার্যক্রম সমান্তরাল ঘটতে. আমি একটি রূপান্তরটি বলছেন যে রক্ষা করতে পারেন “”আমি আপনি এই কার্যকলাপ শুধুমাত্র যদি এই শর্ত সত্য হয় যেতে চাই,”” এবং যেখানে এটি স্টপ আমি আপনাকে দেখাতে পারি. এখন যদি আপনি একটি নির্দিষ্ট বয়স, আপনি সম্ভবত এই কার্যকলাপ ডায়াগ্রাম তাকান এবং মনে করি, হবে “”হুম € |. যে একটি ফ্লো চার্ট দেখে মনে হচ্ছে”” এবং যে ঠিক কি এটা, ব্যতীত আমি না এটা প্রোগ্রামিং পর্যায়ে নেমে করছি. সাধারণত, আমি আমার বিশ্লেষণ এবং নকশা প্রক্রিয়া মোটামুটি প্রথম দিকে একটি কার্যকলাপ ডায়াগ্রাম ব্যবহার ব্যবসা কর্মপ্রবাহ দেখানোর জন্য. আমিও তাদের ব্যবহার দেখানোর জন্য যেখানে আমার ব্যবহারের ক্ষেত্রে প্রতিটি একটি কার্যকলাপ হতে পারে কি ব্যবহারের ক্ষেত্রে ঘটতে হয়েছে চিত্রিত করব. আমিও কার্যকলাপ ডায়াগ্রামে ব্যবহার কিভাবে কিছু আমার ব্যবহারের ক্ষেত্রে মধ্যে প্রবাহিত দেখানোর জন্য.
কিন্তু ইউএমএল সম্পর্কে মহান জিনিস এক তার বহুমুখিতা. তাই যখন আমি জীবনচক্র শুরুতে কার্যকলাপ ডায়াগ্রামে ব্যবহার অন্যান্যের ভিন্ন পর্যায়ে তাদের ব্যবহার করতে পারেন. আমি দেখেছি মানুষ কার্যকলাপ নকশা স্তর যেখানে তারা একটি নির্দিষ্ট শ্রেণীর জন্য আলগোরিদিম একটি অত্যন্ত জটিল সেট ছিল দিকে ডায়াগ্রামে ব্যবহার. এবং অনেক মানুষ তাদের ব্যবহার একটি বর্গ পদ্ধতির মধ্যে প্রবাহ দেখানোর জন্য.
পদ্ধতি. অ্যাক্টরস লাঠি পরিসংখ্যান হিসাবে প্রতিনিধিত্ব করা হয়.
চিত্র 4: অ্যাক্টরস
উদাহরণস্বরূপ যে আমি ইউএমএল এই প্রবর্তনের জন্য কাজ করা একটি কোর্স রেজিস্ট্রেশন সিস্টেমের একটি সামান্য মডেল. এই ইনস্ট্যান্সের মধ্যে সুতরাং, প্রথম জিনিস আমি যখন শুরু আমার বিশ্লেষণ প্রক্রিয়া জিজ্ঞেস করা উচিত, কি হবে “”যারা এই সিস্টেমের সাথে যোগাযোগ করা যাচ্ছে না?””
অবশ্যই রেজিস্ট্রেশন মডেল জন্য, আমি একটি রেজিস্ট্রার অধ্যাপক, এবং একটি ছাত্র আছে. আমি একটি বহিস্থিত বিলিং সিস্টেম আছে. এই বিলিং সিস্টেম এছাড়াও একজন অভিনেতা হিসেবে যোগ্যতা অর্জন করে. (দেখুন, একজন অভিনেতা একজন ব্যক্তির একটি সিস্টেমের সাথে মিথস্ক্রিয়া কিন্তু সিস্টেমের বাইরে € “”এটা কিছু আছে হতে হবে তা নয়.)
একজন ব্যবহারের ক্ষেত্রে একটি ডায়ালগে ব্যবস্থায় একটি অভিনেতা দ্বারা সঞ্চালিত সংশ্লিষ্ট লেনদেনের একটা ক্রম. বা, ইংরেজিতে এটা করা, একটি ব্যবহারের ক্ষেত্রে কার্যকারিতা একটি খণ্ড. আর এখানে কী: এটা একটি সফটওয়্যার মডিউল একটি নয় € “”এটা এমন কিছু বিষয় যা অভিনেতা মান উপলব্ধ করা হয়.
ব্যবহারের ক্ষেত্রে ডিম্বাকৃতি হিসেবে দেখানো হয়, এবং সবচেয়ে সহজ পদ্ধিতি হল উপায় তাদের খুঁজে পেতে আপনার অভিনেতা প্রতিটি তাকান এবং নিজেকে জিজ্ঞাসা কেন তারা ব্যবস্থা ব্যবহার করতে চান হয়. আমার ক্ষেত্রে, আমার রেজিস্ট্রার, পাঠ্যক্রম বজায় রাখা যাচ্ছে আমার অধ্যাপক একটি পালা অনুরোধ করতে যাচ্ছে, আমার ছাত্র সময়সূচী বজায় রাখতে পারবে এবং আমার বিলিং সিস্টেম বিলিং তথ্য পায়. তাই আমি দৃশ্য গ্রাহকের বিন্দু থেকে এটি দিকে তাকিয়ে আছে এবং, জিজ্ঞাসা করে আমার ব্যবহারের ক্ষেত্রে তৈরি “”তাই, মশাই সিস্টেম অভিনেতা, কেন আপনি সিস্টেম ব্যবহার করতে চান? কী মান এই সিস্টেম আপনাকে প্রদান করে?””
পরবর্তী ধাপে, একবার আপনি সনাক্ত করেছি কিভাবে আপনার অভিনেতা সিস্টেমের সাথে আলাপচারিতার করা হবে, আপনার ব্যবহারের ক্ষেত্রে নথিতে নেই. প্রতিটি ব্যবহারের ক্ষেত্রে ঘটনা প্রবাহের সঙ্গে নথিভুক্ত করা প্রয়োজন, এবং এই দৃশ্য অভিনেতা বিন্দু থেকে সম্পন্ন করা হয়. এটা বিস্তারিত কি সিস্টেম যখন ব্যবহারের ক্ষেত্রে মৃত্যুদন্ড কার্যকর করা হয় অভিনেতা প্রদান করতে হবে উচিত. সাধারণত এটা কিভাবে ব্যবহার যদি শুরু হয় এবং শেষ ভালো জিনিস দেখাব. কি জিনিষ যে ব্যবহারের ক্ষেত্রে কি আছে? আপনি ঘটনা স্বাভাবিক প্রবাহ (আমি “”শুভ দিন”” পরিস্থিতি কি কল), যেখানে সবকিছু করতে হবে কাজ করে. তারপর আপনি ঘটনা অস্বাভাবিক প্রবাহ, “”বৃষ্টির দিন”” দৃশ্যকল্প পাবেন. যখন সিস্টেম কাজ করছে না কি ঘটবে? আমি ঘটনা যে আমি সবসময়ই হাসিখুশি দিন দৃশ্যকল্প দিয়ে শুরু আমার প্রবাহ দলিল দ্বারা পেয়েছি.
একটি উদাহরণ হিসাবে গ্রহণ করে, একটি স্বয়ংক্রিয় টেলার মেশিন পর্যন্ত হাঁটা. আপনি এটিএম পর্যন্ত হাঁটতে পারা এবং আপনার কার্ড ঢোকাতে. এটা আপনার পিন নম্বর জন্য অনুরোধ জানানো হবে. আপনি তা লিখুন, এবং আপনাকে জিজ্ঞাসা করা হয় আপনি কি করতে চাই কি. আপনি বলে “”আমি কিছু টাকা চাই.”” এটা যেখানে টাকা থেকে গ্রহণ করা উচিত জিজ্ঞেস করে. আপনি আপনার কারেন্ট একাউন্ট থেকে এটা নিতে তা জানাও. এটা কত জিজ্ঞেস করে. আপনি $ 100.00 বলে. তারপর জাদু ঘটে € | এটা আপনি $ 100.00 দেয়. তারপর এটা জিজ্ঞেস করে আপনি অন্য লেনদেন চান. আপনি কোন বলে. এটা আপনি আপনার কার্ড ফেরত দেয়, আপনি একটি রসিদ দেয়, এবং লেনদেন শেষ হয়. যে শুভ দিন দৃশ্যকল্প এর.
দ্বিতীয় দৃশ্যকল্প. আপনি এটিএম পর্যন্ত যান, আপনার কার্ড ঢোকান, এবং আপনার পিন লিখুন. এটিএম আপনি বলে এটা ভুল পিন আছে. আপনি আপনার নাম্বার আবার লিখুন. আবার আপনাকে যদি বলা হয় যে পিন ভুল. আপনি আমার কোর্স রেজিস্ট্রেশন উদাহরণে, উদাহরণস্বরূপ, যদি আপনি “”যদি এক্স তারপর ওয়াই”” কর্মপ্রবাহ অনেক আছে দেখতে পারেন. যে যেখানে আপনি আপনাকে সাহায্য করার জন্য আপনার গ্রাহক চাই. পেয়ে চুক্তি তাড়াতাড়ি আপনার গ্রাহক এই পরিস্থিতিতে বোঝে এবং বলছেন মানে “”হ্যাঁ, এই হল আমরা কি চাই.”” কারণ তারা অভিনেতা, ব্যবহারের ক্ষেত্রে, এবং তাদের মধ্যে সম্পর্ক দেখানোর ব্যবহারের ক্ষেত্রে, একটি দুর্দান্ত উপায় নিশ্চিত করার জন্য কি আপনি নির্মাণ করছেন সত্যিই কি গ্রাহকের চায় হয়.
চিত্র 5: যদি ডায়াগ্রাম ব্যবহার করুন
সুতরাং আমরা একটি মহান চিত্রটি যে গ্রাফিক্যালি আমাকে কী দেখায় আছে? উত্তর সহজ একটি হল € “”এটি একটি মহান চিত্রটি যে ব্যবস্থার একটি ভাল ওভারভিউ দেখায়. এটা দেখায় কি সিস্টেম (অভিনেতা) এবং কার্যকারিতা যে সিস্টেম (ব্যবহারের ক্ষেত্রে) প্রদান করতে হবে বাইরে. তাহলে সেখানে একটি উত্তরাধিকার সিস্টেম আপনি বিবেচনা করা প্রয়োজন হয়, এখানে যেখানে আপনি এটি দিয়ে মোকাবেলা. আমাকে বাধ্য ইন্টারফেসের এই ধরনের সঙ্গে কাজ করতে খুব প্রকল্পে তাড়াতাড়ি এর মানে হল যে আমি কিভাবে আমি যে কালো বক্স যে আমি পরিবর্তন করতে পারবেন না করার কথা বলতে যাচ্ছি জিনিসটা শুরু কোডিং পর্যন্ত অপেক্ষা প্রত্যাশা নিয়ে মুখোমুখি করা হবে না .
আরও একটি জিনিস আপনি ব্যবহারের ক্ষেত্রে সম্পর্কে জানা উচিত ব্যবহারের ক্ষেত্রে উপলব্ধি. এই “”কিভাবে”” ব্যবহারের ক্ষেত্রে দেখা যায়. ক্রম ডায়াগ্রামে, সহযোগিতা ডায়াগ্রামে, এবং একটি বর্গ রেখাচিত্র যে আমরা অংশগ্রহণকারী ক্লাস দৃশ্য কল: এটি সাধারণত একটি বালতি যে ডায়াগ্রামে তিনটি ভিন্ন ধরনের রয়েছে এর. ব্যবহারের ক্ষেত্রে উপলব্ধির মূলত একসঙ্গে কেস ব্যবহার নকশা সংক্রান্ত হস্তনির্মিত একটি সংখ্যা গোষ্ঠীবদ্ধ করার একটি উপায় আছে.
সিকোয়েন্স রেখাচিত্র
ক্রম ডায়াগ্রামে একটি সময় ক্রমানুসারে সাজানো বস্তুর পারস্পরিক ক্রিয়ার দেন. আমি কি বস্তু এবং কথাবার্তাও আমি ঘটনা প্রবাহের দ্বারা নির্দিষ্ট কার্যকারিতা সম্পন্ন করার জন্য প্রয়োজন হবে তা নির্ধারণ করতে ঘটনা প্রবাহ ব্যবহার করতে পারেন.
চিত্র 6: সিকোয়েন্স ডায়াগ্রাম
চিত্র 6 দেখায় কিভাবে একটি ছাত্র সফলভাবে একটি কোর্স যোগ করা যায়. ছাত্র কিছু তথ্য পূরণ এবং ফর্ম জমা (ওকে জো কল করা যাক). ফর্ম তারপর ম্যানেজারকে আলোচনা এবং বলে “”ম্যাথ 101. জো যোগ”” ম্যানেজার ম্যাথ 101 এটি একটি ছাত্র যোগ করার আছে বলে. ম্যাথ 101 অনুচ্ছেদ 1 বলে যে, “”তুমি খুলে?”” এই ক্ষেত্রে, ধারা 1 জবাব দেওয়া হয়েছে যে তারা খোলা হয়, তাই গণিত 101 এই ছাত্র যোগ করার জন্য অধ্যায় 1 বলে. আবার, ক্রম ডায়াগ্রামে কারণ তারা আপনাকে এবং আপনার গ্রাহক ধাপে ধাপে কি ঘটতে হয়েছে দেন শুরুতে মহান সরঞ্জাম আছে.
দৃশ্য একটি বিশ্লেষণ বিন্দু থেকে, আমি বছর ধরে পেয়েছি ক্রম ডায়াগ্রামে আমাকে প্রয়োজনীয়তা নিয়ে আসতে সহায়তা খুব শক্তিশালী, যে খুঁজে পাওয়া কঠিন, বিশেষত প্রয়োজনীয়তা. ইউজার ইন্টারফেস প্রয়োজনীয়তা, উদাহরণস্বরূপ, কারণ আপনি সবসময় প্রয়োজনীয় যে শুধু testable নয় পেতে মনে কুখ্যাত. এই মত একটি সাধারণ UI ‘প্রয়োজন “”এই সিস্টেম ব্যবহারকারী বান্ধব হতে হবে.”” হয় আপনি কতজন একটি বন্ধুত্বপূর্ণ কম্পিউটার করলি তুই? ডায়াগ্রামে এই ধরনের সুবিধা হল যে একজন অভিনেতা যে একজন ব্যক্তির প্রতিনিধিত্ব করে থেকে আসছে যে লাইন, আপনি আপনার UI ‘তে একটি ক্ষমতা যে ব্যক্তি প্রয়োজনীয় প্রদান করা হয়েছে যে কিছু বলে নেই. অন্য কথায়, আপনি testable ইউজার ইন্টারফেস প্রয়োজনীয়তা থেকে বহিস্কার করতে ক্রম ডায়াগ্রামে ব্যবহার করতে পারেন.
ক্রম ডায়াগ্রামে, অতএব, কি দেখাচ্ছে, হচ্ছেটা প্রয়োজনীয়তা তাড়িয়ে জন্য, এবং গ্রাহকদের সঙ্গে কাজ করার জন্য জন্য ভাল. যে সাধারণত, প্রশ্ন বাড়ে যদিও, কত আপনি তৈরি করতে হবে? আমার উত্তর হচ্ছে, “”যতক্ষণ না আপনি যথেষ্ট না.”” আপনি খুঁজে বের করতে যখন আপনি ক্রম ডায়াগ্রামে যে আপনি একটি পয়েন্ট পৌঁছানোর যেখানে আপনি কোনো নতুন বস্তু খুঁজে পাচ্ছি না, কোনো নতুন বার্তা খোঁজার না চলুন, এবং আপনি বহুবার একই জিনিস টাইপ করছেন যে. জো ম্যাথ 101 যোগদান উদাহরণে, আমরা জানতে পারি যে, প্রক্রিয়া একই হবে যদি জো ইতিহাস 101. সুতরাং, চলতি নিয়ম যোগদান করতে চেয়েছিলেন যে ব্যবহারের ক্ষেত্রে প্রতিটি মৌলিক প্রবাহ জন্য একটি ক্রম চিত্রটি না. উচ্চ পর্যায়ের, ঝুঁকিপূর্ণ পরিস্থিতিতে জন্য একটি ক্রম চিত্রটি কি, এবং যে যথেষ্ট হওয়া উচিত. যে কত ক্রম ডায়াগ্রামে আমি করি.
এখানে মনে রাখতে হবে, যে একটি সহযোগিতা ডায়াগ্রাম শুধু একটি দৃশ্যকল্প একটি ভিন্ন দৃষ্টিভঙ্গি এবং আপনি দৃশ্য আপনার বিন্দু দেখায় যে পেতে ক্রম ডায়াগ্রামে এবং সহযোগিতা ডায়াগ্রামে মধ্যে আগে পিছে চলতে পারে না.
মাঝেমধ্যে, আপনি ফ্রেজ “”মিথস্ক্রিয়া ডায়াগ্রামে.”” শুনতে পারে কখনও কখনও মানুষ সম্মিলিতভাবে একটি সহযোগিতা ডায়াগ্রাম এবং একটি মিথষ্ক্রিয়া ডায়াগ্রাম হিসাবে একটি ক্রম ডায়াগ্রাম পড়ুন হবে.
ক্লাস রেখাচিত্র
একটি বর্গ সাধারণ কাঠামো, সাধারণ আচরণ, সাধারণ সম্পর্ক, এবং সাধারণ শব্দার্থবিদ্যা সঙ্গে অবজেক্টের একটি সংগ্রহ. তুমি তাদের অনুক্রম এবং সহযোগিতা ডায়াগ্রামে বস্তু পরীক্ষা করে খুঁজে, এবং তারা তিনটি বগি সঙ্গে একটি আয়তক্ষেত্র হিসাবে ইউএমএল মধ্যে প্রতিনিধিত্ব করা হয়.
চিত্র 8: ক্লাস
প্রথম কুঠরি, ক্লাসের নাম দেখায় দ্বিতীয় তার কাঠামো (বৈশিষ্ট্যাবলী) দেখায়, এবং তৃতীয় তার আচরণ (অপারেশন) দেখায়. এই বগি দমন করা যেতে পারে, তবে যাতে আপনি শুধু নাম, শুধু নাম ও গুণাবলী, বা সব তিনটি দেখতে পারেন. একটা বিষয়ে তোমার জানা উচিত যে এটা গুরুত্বপূর্ণ, যখন ক্লাস নামকরণ, ডোমেইন এর শব্দভান্ডার ব্যবহার এবং একটি প্রমিত নিতে হয়. এই যেমন ধরুন, আমার ক্লাস সব একবচন বিশেষ্য যে একটি বড় হাতের অক্ষর দিয়ে শুরু হয়. তুমি এটা ভিন্নভাবে না করা চয়ন করতে পারেন, এবং যে কোন ব্যাপার না. কি ব্যাপার যে আপনার প্রকল্পের সামনে আপনি একটি প্রমিত বাছাই এবং এটি দিয়ে বিদ্ধ করা যাতে সব প্রকল্প জুড়ে সামঞ্জস্যপূর্ণ হয়.
ক্লাস রেখাচিত্র আপনি আপনার সিস্টেমের স্ট্যাটিক প্রকৃতি দেন. এই ডায়াগ্রামে ক্লাস এবং একটি সিস্টেম লজিক্যাল দৃশ্য তাদের সম্পর্ক অস্তিত্ব দেন. আপনি একটি মডেল অনেক বর্গ ডায়াগ্রামে থাকবে.
ইউএমএল মডেলিং উপাদান বর্গ ডায়াগ্রামে অন্তর্ভুক্ত রয়েছে:
ক্লাস এবং তাদের কাঠামো ও আচরণ.
এসোসিয়েশন, অ্যাগ্রিগেশন, নির্ভরতা, এবং উত্তরাধিকার সম্পর্ক.
সংখ্যাধিক্য এবং ন্যাভিগেশন ইন্ডিকেটর
ভূমিকা নাম.
চিত্র 9. কটাক্ষপাত এই চিত্রটি দেখায় অপারেশন (আচরণ): কি যে বর্গ মধ্যে একটি বস্তুর মধ্যে নির্বাচন করতে পারবেন. আমি আমার কথাবার্তাও ডায়াগ্রামে এ খুঁজছেন দ্বারা আমার অপারেশন এটি.
চিত্র 9: অপারেশনস
এখানে আমি যে আমি মঠে একটি ছাত্র যোগ করার নিবন্ধন ম্যানেজার জিজ্ঞাসা করতে সক্ষম হতে হবে
101. একটি অপারেশন নামক অনুবাদ যাচ্ছে যে “”addCourse.””
একটি শ্রেণী কাঠামো তার গুণাবলীর দ্বারা প্রতিনিধিত্ব করা হয়. তাই আমি আমার বৈশিষ্ট্যাবলী কিভাবে খুঁজে পেতে? ডোমেইন বিশেষজ্ঞদের সঙ্গে কথা বলে. আমার প্রয়োজনীয়তা এ খুঁজছেন দ্বারা. আমার উদাহরণে, আমি জানতে পারি যে, প্রতিটি কোর্সের নৈবেদ্য একটি সংখ্যা, একটি অবস্থান, এবং একটি সময় হয়েছে. এই তিনটি বৈশিষ্ট্য আউট অনুবাদ.
ক্লাস. (একটি হীরা বর্গ পুরো প্রতিনিধিত্বমূলক পাশে সঙ্গে সংশ্লিষ্ট শ্রেণীর সংযোগ একটি লাইন হিসেবে ইউএমএল দর্শানো.)
€ ¢ নির্ভরশীলতার একটি € “”দুর্ব্বল ফর্ম একটি ক্লায়েন্ট এবং একটি সরবরাহকারী যেখানে ক্লায়েন্ট সরবরাহকারী শব্দার্থিক জ্ঞান নেই মধ্যে সম্পর্ক দেখাচ্ছে. নির্ভরতা বলেছেন “”আমি আপনার সেবা প্রয়োজন, কিন্তু আমি জানি না তুমি রয়েছ.”” (একটি ড্যাশ লাইন সরবরাহকারী ক্লায়েন্ট থেকে নির্দেশ যেমন ইউএমএল দর্শানো.)
সম্পর্ক খুঁজে পেতে, আবার, আমি আমার ক্রম ডায়াগ্রাম থেকে যান. দুটি বস্তুর লাগে “”Talk”” প্রয়োজন হলে, সেখানে হতে হবে একটি উপায়, তাই না (যেমন, তাদের শ্রেণীর মধ্যে একটি সম্পর্ক).
আমি সাধারণত শুরু করা এবং সবকিছু একটি সমিতি আছে. আমি আরো বিশ্লেষণ করছি, আমি খুঁজে পেতে পারে আমি একত্রিত আছে কারণ আমি একটি পিতা বা মাতা-সন্তানের সম্পর্ক যত্ন নিতে যাচ্ছি. যখন আমি নক্সা পর্যায়ের ঢোকা, আমি জানতে যে আমি একটি সমিতি কারণ অন্য কেউ একটি € আমার পদ্ধতি “”তাই আমি এটা একটি নির্ভরতা করা এক মধ্যে যে বস্তু পাস যাচ্ছে প্রয়োজন নাও হতে পারে.
চিত্র 11: সম্পর্ক
চিত্র 11 এইসব সম্পর্ক দেখতে. সমিতি যেমন বলেছেন অধ্যাপক কোর্স, এবং কোর্স কথা বলতে পারেন অধ্যাপক কথা বলতে পারেন. বার্তা শুরু করা যায় এবং তথ্য যে কোন দিক থেকে প্রবাহিত হয় না. সমষ্টি এই ক্ষেত্রে একটি কোর্সের কোর্স অর্ঘ গঠিত হয় পুরো একটি € দিকে হীরা “”থাকার মাধ্যমে দেখানো হয়. এই অ্যাগ্রিগেশন জন্য কারণ আমার ডেভেলপারদের জানাতে যে, তারা যদি এই কোর্সের পরিত্রাণ পেতে, তারা সম্ভবত কিছু কোর্স অর্ঘ সঙ্গে বিশেষ কিছু করতে হবে হবে. নির্ভরতা একটি ড্যাশ লাইন হিসাবে দেখানো হয়. এটা বলার অপেক্ষা রাখে না যে রেজিস্ট্রেশন ম্যানেজার সূচি অ্যালগরিদম উপর নির্ভর করে কিছু করতে. তফসিল অ্যালগরিদম পারেন পদ্ধতি এক একটি প্যারামিটার বা নিবন্ধন ম্যানেজার পদ্ধতি এক স্থানীয়ভাবে ঘোষিত হয়.
সংখ্যাধিক্য এবং ন্যাভিগেশন
সংখ্যাধিক্য সংজ্ঞায়িত কত বস্তু একটি সম্পর্ক অংশগ্রহণের. এটা অন্য ক্লাসের এক উদাহরণস্বরূপ এর সাথে সম্পর্কিত এক শ্রেণীর ইনস্ট্যান্সের সংখ্যা. সম্পর্কের প্রতিটি শেষে জন্য এক: প্রতিটি সমিতি এবং অ্যাগ্রিগেশন জন্য, সেখানে করতে দুটি সংখ্যাধিক্য সিদ্ধান্ত হয়. সংখ্যাধিক্য একটি সংখ্যা হিসাবে প্রতিনিধিত্ব করা হয় এবং একটি * অনেক একটি সংখ্যাধিক্য প্রতিনিধিত্ব করতে ব্যবহৃত হয়.
চিত্র 12: সংখ্যাধিক্য এবং ন্যাভিগেশন
এক অধ্যাপক অবজেক্ট শূন্য টু চার কোর্স অবজেক্টস সঙ্গে সম্পর্কযুক্ত. অবজেক্ট নৈবেদ্য এক কোর্স ঠিক এক অধ্যাপক অবজেক্ট এর সাথে সম্পর্কিত করা হয়. আমি এই ব্যবহার তাকান এবং নিশ্চিত যে এই আমার প্রয়োজনীয়তা হ্যান্ডলগুলি করতে. আমি একটি কোর্স হতে পারে এবং অধ্যাপকদের একটি গুচ্ছ দ্বারা করা দল-শেখানো? না, কারণ এই আমি শুধুমাত্র এক অধ্যাপক থাকতে পারে বলে. আমি একজন অধ্যাপক হতে হবে এবং বিশ্রাম উপর হতে পারে? হ্যাঁ, কারণ এই বলে আমি সম্ভব কোর্স লোড একটি শূন্য আছে. আমি বেশ প্রায়ই সংখ্যাধিক্য ব্যবহার করতে আমাকে ধরে রাখা এবং আমার ব্যবসার নিয়ম বাস্তবায়ন শুরু. আপনি যদি, উদাহরণস্বরূপ, একটি ব্যবসার নিয়ম বলে যে আপনি অন্তত 3 ছাত্র এবং একটি কোর্সের জন্য কোন বেশী 10 একটি সেমিস্টারে দেওয়া থাকতে হবে, এই সংখ্যাধিক্য সংখ্যার আমাকে বল আমি যে এই পরিকল্পনা মধ্যে ব্যবসা নিয়ম অন্তর্ভূক্ত করেছি.
ন্যাভিগেশন একটি তীর দ্বারা দেখানো হয়, এবং যদিও সমিতি ও aggregations দ্বি-মুখী ডিফল্ট দ্বারা হয়, এটা প্রায়ই এক দিক নেভিগেশন সীমিত করা বাঞ্ছনীয়. যখন গৌণ অবধি সীমিত থাকবে, একটি শর ন্যাভিগেশানাল দিক নির্দেশ করে যোগ করা হয়. কিছু বিশ্লেষণ এবং নকশা পর্যায়ক্রমে সময় আমি কি এক আমি কি একাভিমুখী হতে চান তাকান. এই চিত্রটি মধ্যে তীর নির্বাণ দ্বারা, আমি বলতে চাই, নিবন্ধন ম্যানেজার কোর্সের একটি বার্তা পাঠাতে পারেন, কারণ এটা জানে কোর্সের বিদ্যমান. কিন্তু কোর্স যে কোন ধারণা রেজিস্ট্রেশন ম্যানেজার বিদ্যমান রয়েছে, তাই কোর্সের একটি বার্তা সূচনা করতে পারে না. এখন তথ্য তাদের মধ্যে প্রবাহিত হয় না; যদি এটা খোলা উদাহরণস্বরূপ নিবন্ধন ম্যানেজার কোর্সের অনুরোধ করতে পারেন এবং কোর্সের বলতে পারেন যে এটা. কিন্তু শুধুমাত্র রেজিস্ট্রেশন ম্যানেজার যে কথোপকথন শুরু করতে পারেন.
একথাও ঠিক যে এখানে লক্ষ্য হিসাবে আপনি সময় দ্বারা আপনি, ডিজাইনিং সমাপ্ত করেছি যাবে না কারণ এটি উত্তরাধিকার বজায় রাখার জন্য অনেক সহজ পদ্ধতি একটি ত্রিভুজ প্রদর্শন হিসাবে অনেক তীর পেতে হয়. এ থেকে জানা যায় অধ্যাপক একটি রেজিস্ট্রেশন ব্যবহারকারী যে, যেমন ছাত্র. এখন, সতর্কবার্তা একটি শব্দ. উত্তরাধিকার দরকারী হয়, তবে, লক্ষ্য যতটা উত্তরাধিকার হিসেবে আপনার সিস্টেম অনুমতি দেবে ব্যবহার করতে না হয়. আমি কিছু সত্যিই নৃশংস ব্যবস্থা যেখানে তারা উত্তরাধিকার 17 মাত্রা গভীর ছিল দেখেছি. তাহলে তারা এক জিনিস পরিবর্তন, এটি একটি দুর্যোগ ওঠে. তাই চলতি রীতি উত্তরাধিকার ব্যবহার করতে শুধুমাত্র যখন আপনি সত্যিই একটি উত্তরাধিকার অবস্থা আছে কি নেই.
রাজ্য ট্র্যানজিশন রেখাচিত্র
একটি রাষ্ট্র রূপান্তরটি ডায়াগ্রাম একটি প্রদত্ত ক্লাসের জীবন ইতিহাস দেখায়. এটা ঘটনা যে এক রাষ্ট্র থেকে অন্য একটি রূপান্তর হতে, এবং যে সমস্ত কর্ম একটি রাষ্ট্র পরিবর্তনের পরিণাম দেখায়.
চিত্র 14: রাজ্য রূপান্তরটি ডায়াগ্রাম
আমি বস্তু যে ক্লাস সাধারণত গতিশীল আচরণ অনেক আছে জন্য রাষ্ট্র রূপান্তরটি ডায়াগ্রামে ব্যবহার. বোতাম একটি € হয় | বোতাম বন্ধ হয়; আমি এটা জন্য একটি রাষ্ট্র চার্ট করতে যাচ্ছি না. কিন্তু বস্তু ক্লাস গতিশীল আচরণ অনেক আছে যে, আমি সম্ভবত বস্তুর রাজ্যের মধ্যে সন্ধান করতে যাচ্ছি.
আমি একটি রাষ্ট্র, একটি বৃত্তাকার ত্রিভুজ যা দেখিয়ে শুরু. আমি শুরু করতে মার্কিন যুক্তরাষ্ট্র আছে, এবং আমি স্টপ রাজ্যের যা ষাঁড় চোখ হিসাবে দেখানো হয় থাকতে পারে. আমিও রাজ্যের বা পাহারা রূপান্তরের (কিছু যে ঘটতে যখন শুধুমাত্র যখন একটি শর্ত সত্য হয়), অথবা কিছু ঘটে যা যখন আমি রাষ্ট্র ভিতর আছি মধ্যে রূপান্তরের জন্য থাকতে পারে. আমি এই ডায়াগ্রাম তাকান এবং একটি কোর্স-উৎসর্গের জন্য রাষ্ট্র রূপান্তরটি ডায়াগ্রাম দেখতে. এটা আরম্ভের রাজ্যের শুরু হয়, এবং যতক্ষণ না আমি একটি “”ছাত্র যোগ”” বার্তা পেতে আমি যে অবস্থায় থাক. যখন আমি যে মেসেজ পাবেন, আমি শূন্য থেকে ছাত্রের আমার গণনা সেট এবং আমি খোলা অবস্থায় রূপান্তর. আপনি চিত্র 14 যে আমি একটি এন্ট্রি আছে দেখতে পাবেন, এবং কারণ এটা আছে যে আমি যে দশায় পেয়ে দুটি উপায় আছে. এটি বলছে যে কোন ব্যাপার কিভাবে আপনি দশায় আস, আমি তোমাদের ছাত্র রেজিস্টার করতে চান. যখন আমি যে রাষ্ট্র থেকে প্রস্থান, গণনা পরিবর্তন কোর্সে শিক্ষার্থী সংখ্যা ট্র্যাক রাখতে. আমি যতক্ষণ না আমি 10 পেয়ে শিক্ষার্থীদের যুক্ত করে যেতে পারবেন, এবং তারপর আমি বন্ধ রাষ্ট্র থেকে যান. একবার অবশ্য চূড়ান্ত করা হয়, আমি স্টপ অবস্থায় রূপান্তর. কোন ব্যাপার যেখানে আমি তখন যাচ্ছি, যদি আমি বাতিল ইভেন্ট রূপান্তরটি পেতে, আমি আমার ছাত্রদের অবহিত এবং তারপর স্টপ অবস্থায় রূপান্তর.
অবজেক্ট ক্লাস গতিশীল আচরণ অনেক আছে যে, এটি সবকিছু ঘটতে পারে এমন একটি হ্যান্ডল পেতে একটি রাষ্ট্র ডায়াগ্রাম এখান থেকে কি ভাল মূল্য. নিজেকে জিজ্ঞেস করুন কি যখন আমি একটি মেসেজ পাবেন? যখন আমি বার্তা পেতে আমি কি করব? আমি কী বার্তা পাঠাতে হবে? সেই বার্তা অনেক এই উদাহরণে যেখানে যোগ একটি ছাত্র একটি অপারেশন হিসাবে, অবজেক্ট যেটা ক্লাসের অপারেশন হয়ে. এই কর্মের একটি অনেক, গণনা সেটিং গণনা বৃদ্ধিশীল, গণনা চেক মত, এই সব যে বিশেষ বস্তুর ক্লাসের ব্যক্তিগত অপারেশন হয়ে এবং একটি রাষ্ট্র ডায়াগ্রাম যেখানে আমি দেখতে.
যদি আপনি একটি গতিশীল বস্তুর শ্রেণী আছে তুমি কিভাবে জানলে? আবারও বলি, ক্রম ডায়াগ্রামে ফিরে যেতে. আপনি একটি বস্তুর শ্রেণী ক্রম ডায়াগ্রামে অনেক উপর যে আছে এবং এটা পেয়ে এবং বার্তা অনেক পাঠানোর চান, যে একটি ভালো ইঙ্গিত এটি একটি মোটামুটি গতিশীল বস্তু বর্গ এবং এটি সম্ভবত এটা জন্য একটি রাষ্ট্র চার্ট থাকা উচিত. এছাড়াও aggregations, যেখানে আপনি এর অংশ পুরো আছে, আমি যে সমষ্টিগত সমগ্র জন্য রাষ্ট্র চার্ট না. আমি বেশিরভাগ এই কি কারণ যে সমষ্টিগত পুরো প্রায়ই মেসেজিং, যা গতিশীল করে তোলে পরিচালনার জন্য দায়ী.
কম্পোনেন্ট ডায়াগ্রামে
অবশ্যই কোন সিস্টেম একাউন্টে জড়জগৎ গ্রহণ ছাড়াই নির্মিত হতে পারে. যে যেখানে উপাদান ডায়াগ্রামে আসা. তারা সফ্টওয়্যার উপাদান মধ্যে সংগঠন ও নির্ভরতা চিত্রিত, সোর্স কোড উপাদান, সময় উপাদান চালানো, বা একটি এক্সিকিউটেবল কম্পোনেন্ট সহ ব্যবহার করা হয়. চিত্র 15 দেখা উপাদান, পাশ দুটি ছোট আয়তক্ষেত্র দিয়ে একটি বৃহৎ আয়তক্ষেত্র হিসাবে শো হয়.
চিত্র 15: উপাদান
সেই বৃত্তাকার কিছু ইন্টারফেস (প্রায়ই বলা বাতাসা স্বরলিপি) প্রতিনিধিত্ব. এই ক্ষেত্রে, তারা দেখা যায় যে Register.exe উভয় Course.dll এবং People.dll জন্য ইন্টারফেস উপর নির্ভরশীল. এর মানে হল যে যদি এই ইন্টারফেসগুলি পরিবর্তন, এটা Register.exe প্রভাবিত হবে. আমি জানি এই নিয়ম যখন আপনি ইন্টারফেস নির্মাণ করছেন যে বলছেন যে “”তুমি ইন্টারফেস পরিবর্তন করতে পারবে না.”” কিন্তু কেহ আসলে কাজ করে যেখানে যে নিয়ম জারি করা হয়েছে? এই চিত্রটি আমাদেরকে বলে কি ইন্টারফেস ব্যবহার করা হয় কি করে সময় সঞ্চালনযোগ্য এক্সেকিউটেবল ফাইল আমার প্রসেসরের দৌড়াচ্ছে.
চিত্র 16: স্থাপনার ডায়াগ্রাম
ইউএমএল ব্যাপ্ত
শেষ জিনিস আমি ইউএমএল সম্পর্কে জোর করতে চাই যে এটা বাড়ানো যেতে পারে. যখন তারা ইউএমএল নির্মিত, তারা খুব বুদ্ধিমানের মতো উপলব্ধি কোন পথ তারা একটি স্বরলিপি যে মানুষ সব খুশি করতে পারে সব সময় তৈরী করতে পারে সেখানে. তাই তারা আমাদের বাঁধাধরা ধারণা দিয়েছেন. একটি বাঁধাধরা আমি একটি মৌলিক মডেলিং উপাদান গ্রহণ এবং এটি আরো অর্থ দিতে পারেনা. স্টিরিওটাইপ শ্রেণীভুক্ত এবং অ্যাসোসিয়েশনগুলো, উত্তরাধিকার সম্পর্ক, ক্লাস, এবং উপাদান প্রসারিত করতে ব্যবহার করা যেতে পারে.
চিত্র 17: ওয়েব বাঁধাধরা উদাহরণস্বরূপ
চিত্র 17 আমাদের ওয়েব ছকের রেখাচিত্র দেখায়. একটি ওয়েব পাতা সাধারণত কাপড় যে সার্ভার এবং কাপড় যে ক্লায়েন্ট উপর সঞ্চালিত হয় উপর সঞ্চালিত হয়েছে. আপনি ওয়েব ভিত্তিক অ্যাপ্লিকেশন তৈরি করছেন, তা হলে ক্লায়েন্ট উপর চলমান এবং সার্ভার অত্যাবশ্যক গুরুত্ব হল. সুতরাং আমরা ছকের যে দেখা যায় যে, একটি সম্পূর্ণ সেট আছে. সামান্য কায়দা কিছু সার্ভার চালানো যে প্রতিনিধিত্ব. তাই শুধু এই এক ডায়াগ্রাম আমি স্পষ্ট দেখতে পাচ্ছি সার্ভারে কি রান এ খুঁজছেন দ্বারা, কি ক্লায়েন্ট উপর সঞ্চালিত হয়, এবং কি ব্যবসা বস্তু তারা মোকাবেলা করতে হবে.

“——————————————————————————————————————————————————

prijevod podrška: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”UML je standardni jezik za specifikaciju, vizualizaciju, izgradnju, i dokumentovanje svih artefakata softverskog sistema.””
aktivnost Dijagrami
Logičan mjesto za početak hoda kroz neke od UML dijagrama je gledajući dijagrama aktivnosti.
Slika 2: Dijagram aktivnosti
Aktivnost dijagrami pokazuju tok kontrole. Kao što je prikazano na slici 2, možete vidjeti aktivnosti predstavljeni kao zaokružena pravougaonika. Aktivnosti su obično akciju države â € “”navodi da je tranzicija automatski na sljedeći stanje nakon akcije je kompletan. Popunjeni u krug predstavlja početak dijagrama aktivnosti â € “”gdje je tok kontrole počinje. prikazani kao strelice Transitions pokazati kako se iz aktivnosti u aktivnost. Sinkronizacija barova pokazuju kako aktivnosti dogoditi paralelno. Ja mogu čuvati tranziciju koja kaže: “”Hoću da idem u ovu aktivnost samo ako ovo stanje je istina””, i mogu vam pokazati gdje se ne zaustavi. E sad, ako si u određenim godinama, verovatno ćete pogledati ovaj dijagram aktivnosti i misli, “”hmm â € |. Da izgleda kao dijagram toka”” I to je upravo ono što je, osim ne radim ga na nivou programiranja. Tipično, ja koristiti dijagram aktivnosti prilično rano u mom procesu analize i dizajna pokazati poslovnih procesa rada. Ja ću ih koristiti da pokaže gdje je svaki od mojih slučajeva upotrebe može biti aktivnost ilustrirati ono što slučaj upotrebe mora da se dogodi. Takođe koristim aktivnost dijagrame da se pokaže kako stvari teku između mojih slučajeva upotrebe.
Ali, jedan od velikih stvari o UML je njegova svestranost. Dakle, dok sam koristiti aktivnost dijagrame na početku životnog ciklusa, drugi ih mogu koristiti u različitim fazi potpuno. Vidio sam ljudi koriste dijagrami aktivnosti dole na razini dizajn, gdje su imali veoma komplikovana skup algoritama za određenu klasu. I mnogi ljudi koriste ih za prikaz protoka između metoda klase.
sistem. Glumci su predstavljeni kao štap brojke.
Slika 4: Glumci
Primjer koji sam radio za ovaj uvod u UML je malo model sistema registracije naravno. Dakle, u ovom slučaju, prvo što ću učiniti kada počinje moj proces analize je da pitam, “”koji će u interakciji sa ovim sistemom?””
Za model registraciju Naravno, imam matičar, profesor, i student. Imam i spoljni sistema naplate. Ovaj sistem naplate također kvalificira kao glumac. (Vidi, glumac ne mora biti osoba â € “”to je nešto što u interakciji sa sistemom, ali je izvan sistema.)
A upotreba slučaj je niz povezanih transakcija obavlja glumac u sistemu u dijalogu. Ili, da se stavi na engleskom jeziku, a upotreba slučaj je komad funkcionalnosti. I ovdje je ključ: to nije modul softver € “”to je nešto što daje vrijednost glumca.
Koristite slučajevi su prikazani kao ovala, i najlakši način da ih naći je da pogledate na svakom od vaših glumaca i zapitajte se zašto oni žele da koriste sistem. U mom slučaju, moj matičar će održavati nastavnog plana i programa, moj profesor će tražiti spisak, moj student održava raspored, i moj sistem naplate prima informacije obračun. Tako da sam kreiram slučajevima korištenja gledajući ga sa stanovišta kupca gledišta i pita, “”pa, gospodine sistem glumac, zašto želite da koristite sistem? Šta vrednost ovaj sistem pruža vam?””
Sljedeći korak, nakon što ste identifikovali kako će se vaše aktera u interakciji sa sistemom, je do dokumentirati svoj slučajeva upotrebe. Svaki slučaj korišćenja mora biti dokumentovan sa tok događaja, a to se radi sa stanovišta glumca gledišta. Trebalo bi detaljno šta sistem mora osigurati da glumac kada se izvršava korištenje slučaj. Obično to će pokazati stvari poput koliko je korištenje slučaj počinje i završne obrade. Koje stvari to upotreba slučaj ima veze? Vi ćete imati normalan tok događaja (ono što ja nazivam “”Happy Days”” scenarij), gdje sve radi. Onda ćeš dobiti abnormalno tok događaja, u “”crne dane”” scenariju. Šta se dešava kada sistem ne radi? Našao sam dokumentovanjem moj tok događaja koji sam uvijek početi s Happy Days scenarija.
Uzmite kao primjer, hoda se do bankomata. Možete hodati do bankomata i umetnite svoju karticu. On traži PIN broj. Možete ući, a od vas se traži ono što želite učiniti. Kažete “”Želim nešto novca.”” Ona pita gdje treba uzeti novac iz. Reci da je potrebno iz vašeg tekućeg računa. Ona pita koliko. Kažete 100,00 $. Zatim magic happens â € | to vam daje 100,00 $. Onda pita da li želite još jednu transakciju. Možete reći ne. To vam daje svoju karticu nazad, daje račun, a transakcija je gotova. To je sretan dan scenariju.
Drugi scenarij. Ti idi do bankomata, priložite karticu i unesite svoj PIN. ATM kaže da je to pogrešan PIN. Opet unesete broj. Opet ste rekli da PIN nije ispravan. Ti U mom naravno primjer za registraciju, na primjer, možete vidjeti da ima puno “”ako X onda Y”” radne procese. To je gdje želite da vaš klijent da ti pomognem. Dobivanje sporazum rano znači da klijent razumije ovih scenarija i kaže: “”Da, to je ono što želimo.”” Koristite slučajevi su odličan način da se osigura da ono što grade je zaista ono što kupac želi, jer pokazuju glumaca, slučajevi upotrebe, i odnose između njih.
Slika 5: Koristite dijagram slučaja
Dakle, imamo veliki dijagram koji mi šta grafički prikazuje? Odgovor je jednostavan â € “”to je veliki dijagram koji pokazuje dobar pregled sistema. To pokazuje ono što je izvan sistema (glumci) i funkcionalnost da sistem mora osigurati (use). Ako postoji zaostavština sistem treba uzeti u obzir, evo gdje se bavite s tim. Prisiljavanje da radim s ove vrste sučelja vrlo rano u projektu znači da neću biti suočena s mogućnošću čeka kodiranja počinje da shvatim kako ću razgovarati sa da crne kutije koje ne mogu promijeniti .
Još jedna stvar koju treba znati o slučajevima upotreba je realizacija korištenja slučaj. Ovo je “”kako”” upotrebe slučaja. To je obično kanta koja sadrži tri različite vrste dijagrama: slijed dijagrami, saradnja dijagrami, i dijagram klase koji zovemo pogled učešća klase. Koristite realizacije slučaju su u osnovi način grupiranja zajedno veliki broj artefakata koji se odnose na dizajn slučaja korišćenja.
Sequence Dijagrami
Sequence dijagrami pokazuju objekt interakcije raspoređeni u vremenske sekvence. Ne mogu koristiti tok događaja kako bi se utvrdilo što objektima i interakcije ću morati da ostvari funkcionalnosti koje odredi tok događaja.
Slika 6: Sequence dijagram
Slika 6 pokazuje kako je student uspješno se dodaje na kurs. Student (nazovimo ga Joe) popunjava neke informacije i podnosi obrazac. Obrazac onda govori da je direktor i kaže: “”dodati Joe u Math 101.”” Menadžer govori Math 101 da ima dodati student. Math 101 kaže da točki 1 “”jesi li otvoriti?”” U ovom slučaju, Sekcija 1 odgovorima da su otvoreni, tako Math 101 govori sekcija 1 dodati ovaj student. Opet, slijed dijagrami su veliki alat u početku, jer su vas i vaš klijent pokazati korak po korak što treba da se dogodi.
Iz analize tačke gledišta, otkrio sam tijekom godina da slijed dijagrami su vrlo moćni u pomaganju da vozim zahtjevima; posebno uslove koje je teško naći. Korisnički zahtjevi interfejs, na primjer, su poznati, jer izgleda uvijek da se zahtjevi koji su samo ne testirati. A zajednički zahtjev UI ovako je “”ovaj sistem mora biti razumljiv.”” Koliko vas je sreo prijateljski kompjuter? Jedna od prednosti ove vrste dijagrama je da svaka linija iz glumca koji predstavlja osobu, govori da nešto u vašem UI mora osigurati sposobnost potrebna ta osoba. Drugim riječima, možete koristiti slijed dijagrame da istera testirati zahtjevima korisnički interfejs.
Sequence dijagrami su, dakle, dobro za pokazivanje šta se dešava, za vožnju od zahtjeva, a za rad sa klijentima. To obično dovodi do pitanja, iako, koliko ti treba da se stvori? Moj odgovor je, “”dok ne dovoljno.”” Ti ćeš saznati kada radite slijed dijagrama da dođete do tačke kada niste pronalaženje nikakve nove objekte, a ne pronalaženje nove poruke, a da kucate istu stvar iznova i iznova. U primjeru Joe ulaska Math 101, saznajemo da će proces biti isti ako Joe je želio da se pridruže Povijest 101. Dakle, pravilo, napraviti dijagram sekvenci za svaki osnovni tok svake upotrebe slučaj. Da li je dijagram sekvenci za visokom nivou, rizično scenarija, i to bi trebalo biti dovoljno. To je koliko slijed dijagrama radim.
zapamtiti ovdje, da li je to dijagram saradnja je samo drugačiji pogled na scenarij i možete ići naprijed-nazad između slijed dijagrama i suradnju dijagrami da se stav da najbolje ilustruje svoje.
Povremeno, možda ćete čuti izraz “”interakcija dijagramima.”” Ponekad ljudi će kolektivno odnose na dijagram saradnje i dijagram sekvenci kao dijagram interakcije.
Dijagrami klasa
Klasa je skup objekata sa zajedničkim strukture, zajednički ponašanje, zajednički odnose, i zajedničkih semantike. Možete ih pronaći uvidom u objektima u nizu i suradnji dijagrame, i oni su predstavljeni u UML kao pravougaonik sa tri pregrade.
Slika 8: Nastava
Prvi odeljak prikazuje ime klase, drugi pokazuje svoju strukturu (atributa), a treći pokazuje svoje ponašanje (operacije). Ove pregrade mogu biti potisnuti, međutim, tako da možete vidjeti samo ime, samo ime i atribute, ili sva tri. Jedna stvar koju treba da znate je da je važno, kada imenovanja klase, koristiti vokabular domena i odabrati standard. Za ovaj primjer, moj klase su sve imenice u jednini koja počinju velikim slovom. Možete izabrati da to rade drugačije, i to nije bitno. Ono što je bitno je da prije nego što vaš projekt po tebe standard i držati ga tako da je sve u skladu preko projekta.
Dijagrami klasa vam pokazati statičke prirode vašeg sistema. Ovi dijagrami pokazuju postojanje klasa i njihovih odnosa u logičkom pogledu sistema. Imat ćete mnogo dijagrami klasa u modelu.
Elementi UML modeliranje naći u dijagrami klasa uključuju:
Nastava i njihovu strukturu i ponašanje.
Udruženje, agregacije, ovisnosti, i nasljedstvo odnosa.
Mnogostrukost i navigacija pokazatelja
imena ulogu.
Pogledajte Slika 9. Ovaj dijagram prikazuje operacije (ponašanje): što je predmet u toj klasi može učiniti. Mislim da moja operacija gledajući moje interakcije dijagrame.
Slika 9: Operacije
Evo ja kažem da moram biti u mogućnosti da pitaju menadžera registraciju dodali student matematike
101. To će prevesti u operaciji pod nazivom “”addCourse.””
Struktura klase predstavlja svoje atribute. Pa kako da nađem atribute? U razgovoru sa stručnjacima domenu. Gledajući moje zahtjeve. U mom primjeru, ja saznao da svaki predmet ponude ima veliki broj, lokaciju i vrijeme. To znači kako bi tri atributa.
klase. (Zastupljeni u UML kao linija koja povezuje povezanih klasa sa dijamantom pored klasi predstavlja cjelinu.)
â € ¢ Zavisnost â € “”slabiji oblik koji pokazuje odnos između klijenta i dobavljača, gdje klijent nema semantičku znanja dobavljača. A ovisnost kaže: “”Trebam vaše usluge, ali ja ne znam da postoje.”” (Zastupljeni u UML kao isprekidana linija pokazuje od klijenta do dobavljača.)
Da biste pronašli odnosa, još jednom, da se vratim na moju slijed dijagram. Ako dva objekta je potrebno da “”razgovaraju””, mora postojati način da se to učini (i.e., odnos između njihovih klasa).
Ja obično početi i napraviti sve asocijacije. Kao što ja radim više analiza, možda pronađem imam agregacije jer ću morati da se brine o roditelj-dijete odnos. Kada sam se u fazi projektovanja, smatram da možda ne treba povezanost jer je neko drugi neće proći taj predmet u jednu od mojih metoda â € “”tako da bi to ovisnost.
Slika 11: Relationships
Na slici 11 te vidim ove odnose. Kao udruženje kaže profesor može razgovarati sa kursa Nudeći, a kurs Ponuda može razgovarati sa prof. Poruke mogu se pokrenuti i podaci mogu teći iz bilo kojeg smjera. Agregacija je prikazan tako što je dijamant prema cijeli â € “”u ovom slučaju Kurs se sastoji od kurseve. Razlog za ovo agregacije bi da kažem programerima da ako se riješi Naravno, oni će vjerojatno morati učiniti nešto posebno s kurseve. Zavisnosti su prikazani kao isprekidana linija. To govori da je menadžer registracija zavisi od rasporeda algoritam da učini nešto. Raspored Algoritam je bilo parametar jednom od metoda ili lokalno je proglašen za jedan od načina za registraciju Manager.
Mnogostrukost i navigaciju
Mnoštvo određuje koliko objektima učestvuju u vezi. To je broj instanci jedne klase koje se odnose na jednu instancu druge klase. Za svaku udruživanja i agregacije, postoje dva mnoštvo odluka da: jedan za svaki kraj odnosa. Mnoštvo je predstavljena kao broj i * se koristi za predstavljanje mnoštvo mnogih.
Slika 12: Mnoštvo i navigacija
Jedan profesor objekta se odnosi na nula-u-četiri Ponuda Kurs objekata. Jedan Kurs Nudeći objekta se odnosi na točno jedan profesor objekta. I ovo koristiti da pogledam te osigurati da ovaj upravlja mojim zahtjevima. Mogu li biti ponudom predmeta i da se tim-predaje gomila profesora? Ne, jer to kaže da može imati samo jedan profesor. Mogu li biti profesor i biti na odmoru? Da, jer to kaže imam nula moguće opterećenje naravno. Ja koristiti mnoštvo često da mi pomogne da počne snimanje i implementaciju moja poslovna pravila. Ako imate, na primjer, poslovni pravilo koje kaže da mora imati najmanje 3 studenta i ne više od 10 za kurs će biti ponuđen u semestru, ovi brojevi mnoštvo mi reći da sam ugraditi taj posao pravilo u ovom planu.
Navigacija je prikazan strelicom, i iako udruženja i sažimanja su dvosmjerna po defaultu, često je poželjno da se ograniči navigacija na jednom pravcu. Kada je ograničena navigaciju, strelicom se dodaje da ukaže na navigacijske pravcu. Jedna od stvari koje radim u toku faza analize i dizajna je pogledati ono što želim biti uni-smjera. Stavljanjem na strelicu u ovaj dijagram, ja kažem da je Registracija Manager može poslati poruku na teren, jer zna da postoji kursa. Ali Kurs nema pojma da je Registracija Manager postoji, tako da golf ne može pokrenuti poruku. Sada podataka može teći između njih; na primjer Registracija Manager može pitati Naravno, ako je otvoreno, a kurs može se reći da je to. Ali samo za registraciju Manager može započeti taj razgovor.
Očigledno je da je cilj ovdje je da se što više strelice kao što možete od vremena koje ste završili projektiranje, jer je to mnogo lakše sistem za održavanje nasljeđivanju je prikazan sa trokut. To pokazuje da je profesor je registraciju korisnika, kao što je Student. Sada, riječ upozorenja. Nasljeđivanje je koristan, međutim, cilj je da se ne koristi toliko nasljedstvo jer će vaš sistem dozvoljava. Vidio sam neke stvarno brutalne sistemima gdje su duboko imali baštinu 17-nivoa. Ako su promenili jedna stvar, to je postala katastrofa. Dakle, pravilo je da se koriste nasljedstva samo kada zaista imaju u situaciju nasljeđivanja.
State Transition Dijagrami
Dijagram stanje tranzicije prikazuje život povijesti date klase. To pokazuje događaje koji izazivaju prelaz iz jedne države u drugu, i radnje koje rezultiraju iz promjena stanja.
Slika 14: država tranzicije dijagram
I koriste državne tranzicije dijagrame klase objekata koji obično imaju puno dinamičkog ponašanja. Dugme je na € | dugme je isključen; Ja neću učiniti stanja dijagram za to. Ali objekt klase koje imaju puno dinamičkog ponašanja, ja vjerojatno morati pogledati u državama objektima.
Počnem pokazujući države, koja je zaobljeni trokut. Ja mogu imati start države, i ne mogu imati države stop, koji su prikazani kao bikove oči. Ja mogu imati prelaze između država, ili čuvar prelaze (stvari koje se dešavaju kada je samo kada je uslov je istina), ili stvari koje se dešavaju kad sam unutar države. Gledam ovaj dijagram i vidi dijagram države u tranziciji za kurs ponudu. Ona počinje u inicijalizacije državu, i ja ostati u tom stanju dok ne dobijem poruku o “”dodali student””. Kad sam dobiti tu poruku, postavljen sam broj studenata na nulu i ja preći na Open države. Vi ćete vidjeti na slici 14 da imam unos, a razlog zašto je tu je da imam dva načina ulaska u tu državu. On kaže da bez obzira na to koliko ste došli u stanje, želim da se registrujete studenta. Kada sam izlazak te države, brojanje promjene pratiti broj studenata u toku. Ja mogu držati dodajući studente dok ne stignem do 10, a onda idem na Close države. Kada se kurs je završen, ja prijeći na stop države. Bez obzira na to gdje sam tada, ako dobijem Odustani događaja tranzicije, ja obavijestiti svoje studente, a onda prijeći na stop države.
Za klase objekata koji imaju puno dinamičkog ponašanja, to je dobro isplati napraviti dijagram stanja dobiti ručku na sve ono što se mora dogoditi. Zapitajte se šta se dešava kada dobijem poruku? Šta da radim kad dobijem poruku? Koje poruke da sam za slanje? Mnogi od tih poruka postati operacije klase objekta, kao u ovom primjeru gdje dodali student je operacija. Mnogi od tih radnji, kao što je postavljanje posjeta, uvećavanja brojanje, provjeravanje brojanje, ovi svi postaju privatne poslove tog klase objekata i dijagrama stanja je u kojoj vidim.
Kako znate ako imate dinamičan objekat klase? Još jednom, da se vratimo na slijed dijagrama. Ako imate klasu objekta koji je na mnogo slijed dijagrama i postaje i slanje mnogo poruka, to je dobar pokazatelj da je to prilično dinamičan klase objekata i to trebao imati državu grafikon za to. Također za agregacije, gdje imate cijeli njenih dijelova, radim stanja dijagram za svaki agregat cjelini. Ovo radim uglavnom jer je agregatna cijeli je često odgovoran za upravljanje poruka, što ga čini dinamičnim.
komponenta dijagrami
Naravno, postoji sistem može biti izgrađen bez uzimanja u obzir fizički svijet. Tu komponentu dijagrami dolaze u. Oni se koriste za ilustraciju organizacije i ovisnosti među softverskih komponenti, uključujući i kod komponenti izvor, run time komponente, ili izvršnu komponentu. Komponente su predstave kao veliki pravougaonik sa dva manja pravougaonika sa strane, kao što se vidi na slici 15.
Slika 15: Komponente
Te okrugle stvari predstavljaju interfejsa (često naziva lizalicu zapis). U ovom slučaju, oni pokazuju da je Register.exe zavisi sučelja kako Course.dll i People.dll. To znači da ako promenite ovih interfejsa, to će se odraziti na Register.exe. Znam da je ovo pravilo kad izgradnje interfejsa koji kaže: “”ti neće promjeniti jezik sučelja.”” Ali, da li je neko zapravo radi, gdje se sprovodi to pravilo? Ovaj dijagram nam govori šta interfejsi se koriste onim što izvršne rade na mom procesorima.
Slika 16: Deployment dijagram
Proširenje UML
Zadnja stvar koju želim da naglasim o UML je da se može produžiti. Kada su izgradili UML, oni vrlo mudro shvatili da nije bilo ni na koji način nisu mogli stvoriti zapis koji bi mogao zadovoljiti sve ljude svih vremena. Tako su nam dali koncept stereotip. A stereotip kaže da mogu uzeti osnovni element modeliranje i dati više značenja. Stereotipi mogu se koristiti za klasifikaciju i proširiti udruženja, nasljeđivanja odnosa, klase, i komponente.
Slika 17: Web primjer stereotip
Slika 17 prikazuje dijagram naše web stereotipa. Web stranice obično ima stvari koje radi na serveru i stvari koje radi na klijentu. Ako se grade aplikacije na Webu, šta se radi na klijent i server je od vitalnog značaja. Dakle, imamo čitav niz stereotipa koji pokazuju da. Mali kotači predstavljaju stvari koje rade na serveru. Dakle, samo gledajući ovaj dijagram vidim šta radi na serveru, ono što radi na klijentu, i šta poslovnih objekata moraju da se bave.

“——————————————————————————————————————————————————

Подкрепа превод: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”В UML е стандартен език за уточняване, визуализиране, конструиране и документиране на всички артефакти на софтуерна система.””
дейност Diagrams
Логичното място да започнете ходене през някои от диаграмите на UML е като погледнете в дейността диаграми.
Фигура 2: Схема дейност
диаграми активност показват потока на контрол. Както е показано на фигура 2, можете да видите дейности представени като заоблени правоъгълници. Дейностите са обикновено действие членки € “”се посочва, че преходът автоматично към следващото състояние след действието е пълна. Попълнените кръг представлява началото на диаграмата на дейност € “”, където потокът на контрол започва. Преходите са показани като стрелки показват как се движат от дейността на дейност. Синхронизация барове показват как дейности се случват паралелно. Мога да пазят преход, който казва: “”Аз искам да отида на тази дейност, само ако това условие е вярно,”” и аз мога да ти покажа къде го спира. Сега, ако сте на определена възраст, най-вероятно ще разгледаме тази дейност диаграма и си мислят: “”Хм â € |., Което изглежда като технологична схема”” И това е точно това, което е, освен аз не съм го правил на ниво програмиране. Обикновено, аз използвам една диаграма активност сравнително ранен етап от анализ и дизайн процес ми да покажем бизнес работния процес. Аз ще ги използвате, за да покаже, че всеки от случаите ми работа може да бъде в една дейност, за да илюстрира това, което в случая на използване трябва да се случи. Аз също да използвате диаграми на активност, за да се покаже как нещата протичат между случаи ми работа.
Но един от най-великите неща за UML е неговата гъвкавост. Така че, докато аз използвам диаграми дейност в началото на жизнения цикъл, а други могат да ги използват в различна фаза изцяло. Виждал съм хора използват дейност диаграми надолу на ниво проект, където те са имали много сложен набор от алгоритми за определен клас. И много хора ги използват, за да се покаже на потока между методите на класа.
системата. Актьорите са представени като стик цифри.
Фигура 4: Актьори
Примерът, който съм работил за това въведение в UML е малко по модел на система за курс регистрация. Така че в този случай, първото нещо, което ще направя, когато се започва процес моя анализ е да се питат: “”кой ще си взаимодействат с тази система?””
За модела на регистрация Разбира се, аз имам един регистратор, професор и студент. Аз също имам външна система за фактуриране. Тази система за таксуване също се квалифицира като актьор. (Виж, актьор не трябва да бъде лице â € “”това е нещо, което взаимодейства със системата, но е извън системата.)
Случай употреба е поредица от свързани сделки, извършени от участник в системата в диалогов. Или, да го кажем на английски език, а при употреба е парче от функционалност. И тук е ключът: това не е модул за софтуер € “”това е нещо, което дава стойност на актьора.
Използвайте случаи са показани като овали, и най-лесният начин да ги намерите е да разгледаме всеки един от вашите актьори и се запитайте защо те искат да използват системата. В моя случай, регистраторът ми се случва да се поддържа на учебната програма, моят професор ще поиска списък, мой ученик поддържа графика, и фактуриране моята система получава информация за фактуриране. Така че аз се създаде случаи ми работа, като погледнете в него от гледна точка на клиента оглед и пита “”, така, господине система актьор, защо искаш да използват системата? Каква стойност е тази система предоставя на вас?””
Следващата стъпка, след като веднъж сте идентифициран как си актьори се налага да общуват със системата, е документират случаи си работа. Всяка употреба случай трябва да бъде документирана с потока от събития, и това се прави от гледна точка на актьора. Следва подробно какво системата трябва да предостави на актьора, когато случая на употреба се изпълнява. Обикновено това ще покаже неща, като как случай на използване започва и завършва. Какви неща се, че използването случай трябва да се направи? Ще трябва нормалния поток от събития (което аз наричам “”щастливи дни”” сценарий), където всичко работи. След това ще получите ненормално поток от събития, на “”черни дни”” сценарий. Какво се случва, когато системата не работи? Аз открих чрез документиране на моя поток от събития, които винаги съм започват с щастливи дни сценарий.
Вземете за пример, ходене до един банкомат. Ти ходиш до банкомата и поставете вашата карта. Тя пита за ПИН кода. Можете да го въведете, и от вас се иска това, което бихте искали да направите. Вие казвате: “”Искам малко пари.”” Той пита къде са парите трябва да бъдат взети от. Можете да го кажа, за да го вземе от вашата проверка на сметка. Тя пита колко. Казвате $ 100,00. После магията се случва € | Тя ви дава $ 100,00. След това го пита дали искате друга сделка. Можете да кажа не. Тя ви дава картата си обратно, дава разписка, и сделката е приключила. Това е щастлив ден сценарий.
Втори сценарий. Отиваш до банкомата, поставете вашата карта, и въведете вашия ПИН код. Банкоматът ви казва, че е на грешен ПИН код. Можете да въведете номера на вашата отново. Отново ви се казва, че ПИН кодът е неправилен. Можете В моя пример регистрация разбира се, например, можете да видите, че има много “”Ако X тогава у”” работни потоци. Това е мястото, където искате вашите клиенти да ви помогне. Първи договор рано означава, че вашият клиент разбира тези сценарии и казва: “”Да, това е, което искаме.”” Използвайте случаи са чудесен начин да се гарантира, че това, което сте изграждане е наистина това, което клиентът иска, защото те показват актьорите, случаите на използване, както и взаимоотношенията между тях.
Фигура 5: случай на употреба
Така че ние имаме голям диаграма, която графично ми какво показва? Отговорът е прост â € “”това е голяма диаграма, която показва добър преглед на системата. Той показва какво е извън системата (актьори) и функционалността, че системата трябва да осигури (случаи на употреба). Ако има предишен система, което трябва да се вземе под внимание, тук е мястото, където се справят с нея. принуждавайки ме да работя с тези видове интерфейси много ранен етап от проекта означава, че няма да бъдат изправени пред перспективата да чака, докато кодиране започва да разбера как аз ще говоря с тази черна кутия, че не мога да променя ,
Още едно нещо, което трябва да знаете за случаи на употреба е реализацията на ползване случай. Това е “”как”” на използването случая. Това е обикновено една кофа, която съдържа три различни видове диаграми: последователност технологични схеми за съвместна работа, както и диаграма клас, който ние наричаме оглед на участващите класове. Използвайте реализации случаи са основно средство за обединяване на редица артефакти, свързани с проектирането на дело употреба.
Диаграмите на последователностите
Диаграми на последователностите показват взаимодействия обект подредени в последователност време. Мога да използвам потока на събитията, за да се определи какви предмети и взаимодействия аз ще трябва да се изпълни на функционалността, посочен от потока на събитията.
Фигура 6: Диаграма на последователността
Фигура 6 показва как един студент успешно се добавя в един курс. Студентът (нека да го наричат Джо) попълва някаква информация и поддържа формата. Формата след това говори с управителя и казва “”добавите Joe да Math 101.”” Управителят разказва Math 101, че тя трябва да се добави един студент. Math 101 казва, раздел 1 “”са отворите?”” В този случай, Раздел 1 отговори, че те са отворени, така Math 101 казва, раздел 1, за да добавите този студент. Отново, диаграми на последователност са големи средства в началото, защото те ви и вашия клиент покаже стъпка по стъпка какво трябва да се случи.
От гледна точка анализ на оглед, аз открих през годините, че диаграми на последователност са много силни в подпомагането ме закара изисквания; особено изисквания, които са трудно да се намери. изисквания потребителски интерфейс, например, са известни, защото винаги изглежда да получите изисквания, които просто не са проверими. Една обща изискване UI, като това е “”тази система трябва да бъде лесен за употреба.”” Колко от вас са се срещали приятелски компютър? Едно от предимствата на тези видове диаграми е, че всеки ред, идващи от един актьор, който представлява човек, ви казва, че нещо във вашия UI е да се осигури възможност за необходимо от това лице. С други думи, можете да използвате диаграми на последователност, за да изгони проверими изисквания на потребителския интерфейс.
Диаграмите на последователностите са, следователно, добри за показване какво се случва, за да изгонва изисквания, и за работа с клиенти. Това обикновено води до въпроса, все пак, на колко ви е необходимо, за да се създаде? Моят отговор е, “”докато не се направи достатъчно.”” Ще разберете, когато правиш диаграми на последователност, които можете да достигне точката, в която не можете да намерите всички нови обекти, не намери никакви нови съобщения, и в което пишете едно и също нещо отново и отново. В примера на Джо присъедини Math 101, научаваме, че процесът ще бъде същата, ако Джо иска да се присъедини към История 101. Така че, правило, направете диаграма последователност за всеки основен поток на всеки случай употреба. Направете диаграма последователност за високо ниво, рискови сценарии, и че трябва да бъде достатъчно. Ето колко последователност диаграми правя.
да се помни, тук, е, че диаграма сътрудничество е просто различен поглед на един сценарий, и ще можете да се върнете назад и напред между диаграми на последователност и диаграми сътрудничество, за да се счита, че най-добре илюстрира си точка.
От време на време, може да чуете израза “”диаграмите взаимодействия.”” Най- Понякога хората колективно ще се позовават на диаграма сътрудничество и диаграма на последователност като схема на взаимодействие.
клас диаграми
А клас е колекция от предмети с обща структура, обща поведение, общи отношения и общи семантика. Можете да ги намерите чрез изследване на обектите в последователност и сътрудничество диаграми, и те са представени в UML като правоъгълник с три отделения.
Фигура 8: Класове
Първото отделение показва името на класа, а вторият показва неговата структура (атрибути), а третият показва неговото поведение (операции). Тези отделения могат да бъдат потиснати, обаче, така че можете да видите само името, само името и атрибутите, или и трите. Едно нещо, което трябва да знаете е, че това е важно, когато именуване класове, за да използвате речника на домейна и вземете стандартна. За този случай, класове ми са всички единични съществителни, които започват с главна буква. Можете да изберете да го направя по различен начин, и че не е от значение. Важното е, че преди да си проект те взема стандартен и остана с него, така че всичко е последователно навсякъде в проекта.
Клас диаграми ви покажа статичната природа на вашата система. Тези диаграми показват наличието на класове и техните взаимоотношения в логическа гледна точка на една система. Вие ще имате много диаграми класа в един модел.
Елементите на UML моделиране намерени в клас диаграми включват:
Класове и тяхната структура и поведение.
Асоциация, агрегация, зависимост, и наследствените отношения.
показатели множественост и навигация
Роля имена.
Обърнете внимание на фигура 9. Тази диаграма показва операции (поведение): какво може да направи един обект в този клас. Намирам моите операции, като погледнете в моите взаимодействия диаграми.
Фигура 9: Операции
Тук искам да кажа, че аз трябва да бъде в състояние да попитам управителя на регистрация, за да добавите един студент да Math
101. Това ще се изрази в една операция, наречена “”addCourse.””
Структурата на клас се представлява от атрибути. И така, как мога да намеря моите качества? Чрез говорим за експерти в областта. Като гледам в моите изисквания. В моя пример, да науча, че всеки разбира предлагане има номер, място и време. Това се превежда до три атрибути.
класове. (Представител в UML като линия, свързваща съответните класове с диамант в непосредствена близост до класа, представляваща цялото.)
â € ¢ Зависимост â € “”по-слаба форма, показваща връзката между клиент и доставчик, когато клиентът не разполага семантично знание на доставчика. А зависимостта казва “”Имам нужда от вашите услуги, но аз не знам, че съществува.”” (Представител в UML като пунктирана линия в посока на клиента към доставчика.)
За да намерите връзки, за пореден път, аз се върна в моята диаграма последователност. Ако два обекта трябва да “”говори””, трябва да има средства, за да направи това (т.е., връзката между техните класове).
Аз обикновено започват и да направи всичко за асоцииране. Както правя повече анализи, мога да намеря Имам агрегация, защото аз ще трябва да се грижи за връзката родител-дете. Когато отида в етапа на проектиране, да разбера, че не може да се наложи за асоцииране, защото някой друг ще мине този обект в един от моите методи â € “”, така че аз го зависимостта правят.
Фигура 11: Връзки
На Фигура 11, което виждате тези взаимоотношения. Като асоциация, казва професорът може да се говори за Course предлагане, и на курса предлагане може да се говори за професора. Съобщенията могат да бъдат инициирани и данни могат да се движат във всички посоки. Сумиране е показана чрез като диаманта към цялата € “”в този случай курс се състои от предлагане на курса. Причината за това агрегация би било да кажа на моите разработчиците, че ако те се отървете от този курс, те най-вероятно ще трябва да направим нещо специално с предложения на курса. Зависимостите са показани като пунктирана линия. Той казва, че мениджърът на регистрация зависи от График алгоритъм, за да се направи нещо. The График алгоритъм е било параметър на един от методите, или е обявен на местно ниво, като един от методите на мениджъра на регистрация.
Многообразието и навигация
Многообразието определя колко много обекти участват в една връзка. Това е броят на копията на един клас, свързани с една инстанция на друга класа. За всяка асоциация и агрегация, има два кратност решения, за да правят: една за всеки край на връзката. Многообразието се представя като брой и * се използва за представяне на множество много.
Фигура 12: Многообразието и навигация
Един професор обект е свързано с нула до четири Предлагащи Course обекти. Един курс Предлагането на обекта е свързано с точно един професор Object. Аз използвам това, за да разгледаме и да се гарантира, че тази дръжки на моите изисквания. Мога ли да бъда жертва на курса и се екип учени от куп професори? Не, защото това се казва I може да има само един професор. Мога ли да бъда професор и да бъде на отпуск? Да, защото това се казва имам нула, колкото е възможно натоварване разбира се. Аз използвам множественост доста често, за да ми помогне да започнете да снимате и прилагане моите бизнес правила. Ако имате, например, правило бизнес, който казва, че трябва да има поне 3 студенти и не повече от 10 за един курс да се предлагат в един семестър, тези кратност номера ми казват, че съм включен, че бизнес правило в този план.
Navigation е показано със стрелка, и въпреки асоциации и струпвания са двупосочни по подразбиране, често е желателно да се ограничи навигация в една посока. Когато навигация е ограничен, се добавя стрелка за указване на навигационна посока. Едно от нещата, които правя по време на анализа и дизайна на фазите на е погледнете това, което искам да бъде еднопосочно. С пускането на стрелката в тази схема, аз казвам, че управителят на регистрация може да изпрати съобщение до разбира се, защото тя знае, съществува курса. Но курс няма представа, че съществува управителя на регистрация, така че разбира се, не може да започне съобщение. Сега данни могат да се движат между тях; например управителя на регистрация може да поиска от Разбира се, ако това е отворен и курса може да се каже, че това е така. Но само на управителя на регистрация може да започне този разговор.
Очевидно целта тук е да се получи възможно най-много стрели, колкото можете по времето, когато сте готови с дизайна, защото това е много по-лесно система за поддържане на наследяване е показан с триъгълник. Това показва, че професорът е регистрация на потребител, както е студент. Сега, една дума на предупреждение. Наследяването е полезно, обаче, целта е да не се използва като много наследство, както е вашата система ще позволи. Виждал съм някои наистина брутални системи, при които те са имали наследството 17-нива в дълбочина. Ако те се промени едно нещо, то се превръща в бедствие. Така че правилото е да се използва наследството само когато наистина имаме една ситуация наследство.
Преходното състояние Diagrams
Диаграма на преходите показва историята на живота на даден клас. Това показва събитията, които причиняват преход от едно състояние в друго, както и действията, които са резултат от промяна в състоянието.
Фигура 14: държавна преход диаграма
Аз използвам държавни преход диаграми за класовете от обекти, които обикновено имат много динамично поведение. Бутонът е по € | на бутона е изключен; Аз няма да направя състояние диаграма за това. Но класове от обекти, които имат много динамично поведение, аз съм най-вероятно ще трябва да погледне в състоянията на обектите.
Започвам от показващ положение, което е заоблен триъгълник. Мога да имат начални състояния, и аз може да има стоп-членки, които са показани като бикове очи. Аз също може да има преход между държави, или охрана преходи (неща, които се случват, когато само когато условие е вярно), или неща, които се случват, когато съм вътре в държавата. Гледам тази схема и да видим преход диаграмата състояние за предлагане разбира се. Тя започва в състояние на инициализация, и остана в това състояние, докато не получите съобщение за “”добавяне на студент””. Когато получите това съобщение, задам брой на студент до нула и аз преход към Open държавата. Ще видите на фигура 14, която имам на запис, и причината, поради която той е там е, че имам два начина за получаване в това състояние. Той казва, че няма значение колко сте влезе в държавата, искам да се регистрирате на студента. Когато излезете от това състояние, промени за преброяване, за да следите на броя на студентите в курса. Мога да поддържа добавянето на учениците, докато не стигнем до 10, и след това отивам на Close държавата. След курса се финализира, аз преход към състояние на стоп. Без значение къде съм след това, ако получа Отмени прехода събитие, аз уведоми студентите си и след това преминете към състоянието на стоп.
За класовете обекти, които имат много динамично поведение, това е и си заслужава да се направи диаграма на състоянията, за да се справя по всичко, което трябва да се случи. Запитайте се какво се случва, когато получавам съобщение? Какво да направя, когато получа съобщението? Какви послания да съм, за да изпратите? Много от тези съобщения се превърне операции на класа на обекта, като в този пример, когато добавите студент е операция. Много от тези действия, като определяне на броя, увеличаване на броя, проверка на графа, те всички стават частни операции на този конкретен обект клас и диаграма на състоянията е мястото, където виждам, че.
Откъде знаеш, че ако имате динамичен обект клас? За пореден път, се върна в диаграмите на последователността. Ако имате клас обект, който е на много диаграми на последователност и става все по-и изпращане на много съобщения, че това е добра индикация, че е доста динамичен обект клас и то вероятно трябва да има държавна диаграма за това. Също така за съвкупности, където ще трябва цялото на съставните му части, което правя състояние диаграма за всеки агрегат цяло. Аз правя това, най-вече заради това агрегат цяло е често отговаря за управлението на съобщения, което го прави динамичен.
Компонент диаграми
Разбира се няма система може да бъде изградена без да се вземат под внимание на физическия свят. Това е, когато компонентни диаграми идват в. Те се използват за илюстриране на организациите и зависимостите между софтуерни компоненти, включително и изходния код компоненти, тичам компоненти време или изпълним компонент. Компонентите са показва като голям правоъгълник с две по-малки правоъгълници на страна, както се вижда на фигура 15.
Фигура 15: Компоненти
Тези кръгли неща представляват интерфейси (често наричан близалка нотация). В този случай, те показват, че Register.exe зависи интерфейси към както Course.dll и People.dll. Това означава, че ако тези връзки се променят, това ще се отрази на Register.exe. Знам, че има това правило, когато сте изграждане интерфейси, която казва “”Ти не трябва да се променя интерфейса.”” Но дали някой действително работят, където се прилага това правило? Тази диаграма ни казва какво интерфейси се използват от какво изпълними се изпълняват на моите процесори.
Фигура 16: Deployment диаграма
Удължаване на UML
Последното нещо, което искам да подчертая, за UML е, че той може да бъде удължен. Когато те построен на UML, те много мъдро разбра, че не е имало начин те биха могли да се създаде система за означаване, че може да угоди на всички хора през цялото време. Така че те ни дадоха идеята за стереотип. Стереотипът казва мога да взема една основна моделиране елемент и да го даде по-голям смисъл. Стереотипите могат да бъдат използвани за класифициране и разшири асоциации, наследствените отношения, класове, и компоненти.
Фигура 17: Web стереотип пример
Фигура 17 показва диаграмата на нашите уеб стереотипи. А уеб страница обикновено има неща, който работи на сървъра и неща, който работи на клиента. Ако сте изграждане на уеб-базирани приложения, това, което се изпълнява на клиента и сървъра е от жизнено важно значение. Така че ние имаме цял набор от стереотипи, които показват, че. Малките колела представляват неща, които се изпълняват на сървъра. Така че просто като погледнете в тази схема, мога да видя това, което се изпълнява на сървъра, това, което се изпълнява на клиента, и това, което бизнес обекти, те трябва да се справят с.

“——————————————————————————————————————————————————

traducció de suport: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”L’UML és el llenguatge estàndard per especificar, visualitzar, construir i documentar tots els artefactes d’un sistema de programari.””
Els diagrames d’activitat
El lloc lògic per començar a caminar a través d’alguns dels diagrames UML és mirant als diagrames d’activitat.
Figura 2: Diagrama d’activitat
diagrames d’activitat mostren el flux de control. Com s’il·lustra a la Figura 2, es pot veure activitats representades en forma de rectangles arrodonits. Les activitats són típicament els estats d’acció â € “”afirma que la transició automàticament al següent estat després de l’acció s’ha completat. L’ompliment el cercle representa el començament del diagrama d’activitat â € “”on el flux de sortides de control. Les transicions es mostren com fletxes mostren com es passa d’una activitat a una altra. barres de sincronització mostren com succeeixen les activitats en paral·lel. Puc guardar una transició que diu: “”Vull que vagi a aquesta activitat només si es compleix aquesta condició,”” i els puc mostrar on s’atura. Ara si vostè és d’una certa edat, és probable que mira aquest diagrama d’activitat i pensar, “”hmm â € | que s’assembla a un diagrama de flux.”” I això és exactament el que és, excepte que no estic fent baixar a nivell de programació. En general, faig servir un diagrama d’activitat bastant aviat en el meu procés d’anàlisi i disseny per mostrar el flux de treball empresarial. També utilitzarem per mostrar on cada un dels meus casos d’ús podria estar en una activitat per il·lustrar el que cas d’ús ha de succeir. També ús dels diagrames d’activitat per mostrar com flueixen les coses entre els meus casos d’ús.
Però una de les grans coses sobre l’UML és la seva versatilitat. Així, mentre que jo faig servir els diagrames d’activitat al començament del cicle de vida, altres poden utilitzar-los en una fase completament diferent. He vist persones que utilitzen l’activitat a baix de diagrames a nivell de disseny on tenien un conjunt molt complicat d’algoritmes per a una classe particular. I moltes persones els utilitzen per mostrar el flux entre els mètodes d’una classe.
el sistema. Els actors es representen com figures de pal.
Figura 4: Actors
L’exemple que vaig treballar per a aquesta introducció a UML és un petit model d’un sistema d’inscripció al curs. Per tant, en aquest cas, el primer que faria quan començava el meu procés d’anàlisi és preguntar, “”¿qui va a interactuar amb aquest sistema?””
Per al model d’inscripció en el curs, tinc un registrador, un professor i un estudiant. També tinc un sistema de facturació extern. Aquest sistema de facturació també es qualifica com un actor. (Vegeu, un actor no ha de ser un una persona € “”és qualsevol cosa que interactua amb el sistema, però es troba fora del sistema).
Un cas d’ús és una seqüència d’operacions vinculades realitzades per un actor en el sistema en un diàleg. O, per dir-ho en anglès, un cas d’ús és una part de la funcionalitat. I aquí hi ha la clau: no és un mòdul de programari â € “”és una cosa que aporta valor a l’actor.
Els casos d’ús es mostren com ovals, i la forma més fàcil de trobar-los és mirar a cadascun dels seus actors i es pregunta què és el que volen utilitzar el sistema. En el meu cas, el meu registrador va a mantenir el pla d’estudis, el meu professor va a demanar una llista, el meu estudiant manté la programació, i el meu sistema de facturació rep la informació de facturació. Així que crec meus casos d’ús amb mirar-ho des del punt de vista del client i preguntar, “”de manera que, l’actor sistema senyor, ¿per què voleu utilitzar el sistema? Quin valor té aquest sistema proporciona a vostè?””
El següent pas, un cop que hagi identificat com els seus actors interactuaran amb el sistema, és do documentar els seus casos d’ús. Cada cas d’ús ha de ser documentat amb el flux dels esdeveniments, i això es fa des del punt de vista de l’actor. S’ha de detallar el que el sistema ha de proporcionar a l’actor quan s’executa el cas d’ús. Generalment es mostrarà coses com la forma del cas d’ús comença i acaba. Quines coses que cas d’ús té a veure? Vas a haver el flux normal dels esdeveniments (el que dic l’escenari “”dies feliços””), on tot funciona. Després li posen el flux anormal d’esdeveniments, l’escenari de “”dia de pluja””. Què passa quan el sistema no funciona? He trobat mitjançant la documentació de la meva flux d’esdeveniments que sempre començar amb l’escenari feliços dies.
Prenguem com a exemple, caminar fins a un caixer automàtic. Es pot caminar fins al caixer automàtic i inserir la seva targeta. Se li demana el seu número de PIN. Entrar-hi, i se li pregunta què li agradaria fer. Vostè diu “”Vull una mica de diners.”” Es pregunta on són els diners ha de ser pres de. Vostè li diu a prendre del seu compte de xecs. Es pregunta quant. Dius $ 100,00. A continuació, la màgia passa â € | que li dóna $ 100,00. A continuació, se us demanarà si desitja una altra transacció. Vostè diu que no. Se li dóna la seva targeta de nou, li dóna un rebut, i la transacció ha acabat. Aquest és l’escenari feliç dia.
Segon escenari. Pots anar fins al caixer automàtic, inseriu la targeta, i introduir el PIN,. El caixer automàtic et diu que és un PIN incorrecte. Introdueix el número de nou. Un cop més se li diu que el PIN és incorrecte. Vostè En el meu curs exemple de registre, per exemple, es pot veure que hi ha una gran quantitat de “”Llavors, si X I”” els fluxos de treball. Aquí és on vostè vol que el seu client per ajudar-lo cap a fora. Aconseguir un acord d’hora vol dir que el seu client entén aquests escenaris i diu “”sí, això és el que volem.”” Els casos d’ús són una gran manera d’assegurar-se que el que estem construint és realment el que vol el client, a causa que mostren els actors, els casos d’ús, i les relacions entre ells.
Figura 5: Diagrama de casos
Per tant, tenint un gran diagrama que m’ho mostra gràficament? La resposta és un simple € “”és un gran diagrama que mostra una bona visió general del sistema. Mostra el que està fora del sistema (actors) i la funcionalitat que el sistema ha de proporcionar (casos d’ús). Si hi ha un sistema heretat cal prendre en consideració, aquí és on ha de tractar amb ell. m’obliga a treballar amb aquests tipus d’interfícies molt d’hora en el projecte vol dir que no se li enfronta amb la perspectiva d’esperar fins que s’inicia la codificació d’esbrinar com vaig a parlar amb aquest quadre negre que no puc canviar .
Una cosa més que vostè ha de saber sobre els casos d’ús és el cas d’ús realització. Aquest és el cas de “”com”” de la utilització. En general és una galleda que conté tres diferents tipus de diagrames: diagrames de seqüència, diagrames de col·laboració i un diagrama de classes que anomenem un punt de vista de les classes participants. Utilitza realitzacions de casos són bàsicament una forma d’agrupar junts un nombre d’artefactes relacionats amb el disseny d’un cas d’ús.
Els diagrames de seqüència
Els diagrames de seqüència mostren interacció entre els objectes disposats en una seqüència de temps. Puc utilitzar el flux d’esdeveniments per a veure els objectes i les interaccions que haurà de complir la funcionalitat especificada pel flux d’esdeveniments.
Figura 6: Diagrama de Seqüència
La figura 6 mostra com un estudiant amb èxit s’agrega a un curs. L’estudiant (anem a dir-Joe) plena d’alguna informació i envia el formulari. El formulari i després parla amb el gerent i diu “”afegir a Joe Matemàtiques 101.”” El gerent diu Matemàtiques 101 que ha d’afegir un estudiant. Math 101 diu a la Secció 1 “”està obert?”” En aquest cas, Secció 1 respostes que estan oberts, pel que diu la secció de Matemàtiques 101 1 per a afegir aquest estudiant. Una vegada més, els diagrames de seqüència són una gran eina en el principi, ja que vostè i el seu client mostren pas a pas el que ha de succeir.
Des del punt de vista d’anàlisi, el que he trobat en els últims anys que els diagrames de seqüència són molt poderosa per ajudar em porti requisits; especialment els requisits que són difícils de trobar. requisits de la interfície d’usuari, per exemple, són coneguts perquè sempre sembla que tenen requisits que simplement no són comprovables. Un requisit de la interfície d’usuari comú d’aquest tipus és “”aquest sistema ha de ser fàcil d’utilitzar.”” Quants de vosaltres heu conegut a un equip amigable? Un dels avantatges d’aquest tipus de diagrames és que cada línia que ve d’un actor que representa una persona, li diu que alguna cosa en la seva interfície d’usuari ha de proporcionar una capacitat necessària per a aquesta persona. En altres paraules, pot utilitzar els diagrames de seqüència per expulsar els requisits de la interfície d’usuari comprovables.
Els diagrames són, per tant, bons per mostrar el que està passant, per l’expulsió dels requisits, i per treballar amb els clients. Que en general porta a la pregunta, però, de quants vostè necessita per crear? La meva resposta és, “”fins que prou.”” Aneu a saber quan ho fa diagrames de seqüència que s’arriba a un punt en què no està trobant els objectes nous, en no trobar algun missatge nou, i que s’està escrivint la mateixa cosa una i altra vegada. En l’exemple de Joe unir-se Matemàtiques 101, veiem que el procés seria el mateix si Joe volia unir-se Història 101. Així, regla general, fem un diagrama de seqüència per a cada flux bàsic de cada cas d’ús. Fer un diagrama de seqüència d’alt nivell, els escenaris de risc, i això hauria de ser suficient. Aquesta és la quantitat diagrames de seqüència que faig.
a recordar aquí, que és un diagrama de col·laboració és només un punt de vista diferent d’un escenari i es pot anar i venir entre els diagrames de seqüència i diagrames de col·laboració per obtenir la vista que millor il·lustra el seu punt.
De tant en tant, és possible escoltar la frase “”diagrames d’interacció.”” A vegades la gent va a referir-col·lectivament a un diagrama de col·laboració i un diagrama de seqüència com un diagrama d’interacció.
Diagrames de Classes
Una classe és un conjunt d’objectes amb estructura comuna, comportament comú, les relacions comunes, i la semàntica comuns. Se’ls troba mitjançant l’examen dels objectes de seqüència i de col·laboració diagrames, i que està representat en l’UML com un rectangle amb tres compartiments.
Figura 8: Classes
El primer compartiment mostra el nom de la classe, la segona mostra la seva estructura (atributs), i la tercera mostra el seu comportament (operacions). Aquests compartiments es poden suprimir, però, pel que es pot veure només el nom, només el nom i els atributs, o els tres. Una cosa que també ha de saber és que és important, en assignar noms a les classes, utilitzar el vocabulari del domini i triar un estàndard. Per a aquest exemple, les meves classes són tots els substantius singulars que comencen amb una lletra majúscula. Vostè pot optar per fer-ho de manera diferent, i que no importa. El que importa és que abans que el seu projecte d’escollir un estàndard i s’enganxa amb ell perquè tot sigui coherent en tot el projecte.
Classe diagrames que mostren la naturalesa estàtica del seu sistema. Aquests diagrames mostren l’existència de classes i les seves relacions en la vista lògica d’un sistema. Vostè tindrà moltes diagrames de classes en un model.
Els elements de modelatge UML que es troben en els diagrames de classes inclouen:
Les classes i la seva estructura i comportament.
relacions d’associació, agregació, de dependència, i l’herència.
indicadors de multiplicitat i de navegació
noms de rols.
Fer una ullada a la figura 9. Aquest diagrama mostra les operacions (comportament): què és un objecte d’aquesta classe pot fer. Trobada meves operacions per mirar les meves diagrames de les interaccions.
Figura 9: Operacions
Aquí estic dient que he de ser capaç de demanar a l’administrador de registre per afegir un estudiant de Matemàtiques
101. Això traduirà en una operació anomenada “”addCourse.””
L’estructura d’una classe està representada pels seus atributs. Llavors, com puc trobar els meus atributs? En parlar amb els experts de domini. En mirar a les meves necessitats. En el meu exemple, m’assabento que cada oferta de golf té un nombre, un lloc i un temps. Això es tradueix a tres atributs.
classes. (Representat en l’UML com una línia que uneix les classes relacionades amb un diamant al costat de la classe que representa el tot.)
â € ¢ La dependència â € “”una forma més feble que mostra la relació entre un client i un proveïdor en el qual el client no té coneixement semàntic del proveïdor. Una dependència diu “”Necessito seus serveis, però no sé que existeixes.”” (Representat en l’UML com una línia discontínua que apunta des del client al proveïdor.)
Per trobar relacions, un cop més, torno al meu diagrama de seqüència. Si dos objectes han de “”parlar””, ha d’haver un mitjà per fer-ho (és a dir, una relació entre les seves classes).
Em solen començar a sortir i fer tot el que una associació. Com que estic fent més anàlisis, podria trobar que tinc una agregació perquè vaig a haver de tenir cura d’una relació pare-fill. Quan em fico en la fase de disseny, m’assabento que pot ser que no es necessita una associació perquè algú més passarà aquest objecte en un dels meus mètodes â € “”pel que el converteixen en una dependència.
Figura 11: Relacions
A la figura 11 es veu que aquestes relacions. Com a associació diu que el professor pot parlar amb l’oferiment del curs, i l’Oferta de golf pot parlar amb el professor. Els missatges poden ser iniciats i dades poden fluir des de qualsevol direcció. L’agregació es mostra per tenir el diamant cap a tot el â € “”en aquest cas un Curs es compon d’Oferta de cursos. La raó d’aquesta agregació seria dir-li als meus desenvolupadors que si es desfan d’aquest curs, que probablement hauran de fer alguna cosa especial amb l’oferta de cursos. Les dependències es mostren com una línia discontínua. És com dir que el gestor de registre depèn de la Llista Algorisme per fer alguna cosa. La Llista algoritme és o bé un paràmetre a un dels mètodes o es declara localment per un dels mètodes del Gestor de registre.
La multiplicitat i la navegació
Multiplicitat defineix quants objectes participen en una relació. És el nombre d’instàncies d’una classe relacionades amb una instància de l’altra classe. Per a cada associació i agregació, hi ha dues decisions multiplicitat de fer: una per a cada extrem de la relació. La multiplicitat es representa com un nombre i un * s’utilitza per representar una multiplicitat de molts.
Figura 12: La multiplicitat i la navegació
Un professor d’objecte es relaciona amb zero a quatre objectes que ofereixen aquest curs. Un golf Oferint objecte es relaciona amb exactament un professor d’objectes. L’utilitzo per mirar i assegurar-se que aquesta fa servir els meus requisits. Puc ser un oferiment de golf i ser ensenyat equip per un grup de professors? No, perquè això diu que només pot tenir un professor. Puc ser un professor i ser un any sabàtic? Sí, perquè això diu que tinc un zero com sigui possible la càrrega acadèmica. Jo ús multiplicitat bastant sovint que m’ajudi a iniciar la captura i execució de les meves regles de negoci. Si vostè té, per exemple, una regla de negoci que diu que vostè ha de tenir com a mínim 3 estudiants i no més de 10 per a un curs que s’oferirà en un semestre, aquests números multiplicitat digues-me que he incorporat regles de negoci en aquest pla.
Navegació es mostra per una fletxa, i tot i que les associacions i agregacions són bidireccionals per defecte, sovint és desitjable restringir de navegació per a una direcció. Quan navegació està restringit, s’afegeix una punta de fletxa per indicar la direcció de navegació. Una de les coses que faig durant les fases d’anàlisi i disseny és mirar al que jo vull ser uni-direccional. En posar la fletxa en aquest diagrama, dic que l’Administrador d’inscripció es pot enviar un missatge a golf, ja que sap que existeix el Curs. Però el curs no té idea que hi ha l’Administrador de registre, per la qual cosa el Curs no pot iniciar un missatge. Ara dades poden fluir entre ells; per exemple, l’Administrador d’inscripció es pot demanar al curs si està obert i el Curs pot dir que es tracta. No obstant això, només l’administrador de registre pot iniciar la conversa.
Òbviament, l’objectiu aquí és aconseguir el major nombre de fletxes com es pot de moment en què hagi acabat el disseny, perquè és un sistema molt més fàcil mantenir l’herència es mostra amb un triangle. Això demostra que el professor és un usuari de registre, com és l’estudiant. Ara, una paraula d’advertència. L’herència és útil, però, l’objectiu és no utilitzar l’herència que el seu sistema ho permeti. He vist alguns sistemes realment brutals on tenien herència de 17 nivells de profunditat. Si han canviat d’una cosa, es va convertir en un desastre. Així que la regla d’or és usar herència només quan realment tenen una situació d’herència.
Els diagrames de transició d’estats
Un diagrama de transició d’estat mostra la història de vida d’una classe determinada. Mostra els esdeveniments que causen una transició d’un estat a un altre, i les accions que resulten d’un canvi d’estat.
Figura 14: Diagrama de transició d’estats
Jo ús els diagrames de transició d’estats per a les classes d’objectes que típicament tenen un munt de comportament dinàmic. El botó està activat â € | el botó està apagat; Jo no vaig a fer un diagrama d’estat per a això. Però les classes d’objectes que tenen una gran quantitat de comportament dinàmic, probablement vaig a haver de mirar els estats dels objectes.
Començament mostra un estat, que és un triangle arrodonit. Puc tenir estats d’inici, i puc tenir estats d’aturada, que es mostren com bous ulls. També puc tenir transicions entre estats o transicions de guàrdia (coses que succeeixen quan només quan una condició és vertadera), o les coses que succeeixen quan estic a l’interior de l’estat. Miro a aquest diagrama i veure el diagrama de transició d’estats per a una oferta de cursos. S’inicia en l’estat d’inicialització, i em quedo en aquest estat fins que arribi un missatge de “”afegir estudiant””. Quan arribo a aquest missatge, em vaig posar el meu compte d’estudiant a zero i que la transició a l’estat obert. Veuràs a la Figura 14 que tinc una entrada, i la raó per la qual està aquí és que tinc dues maneres d’entrar en aquest estat. Es diu que no importa com s’arriba a l’estat, vull que es registri l’estudiant. Quan surto d’aquest estat, els canvis en el recompte per fer un seguiment del nombre d’estudiants en el curs. Que pugui seguir afegint als estudiants fins que arribi a 10, i després anar al Primer estat. Un cop finalitzat el curs, puc fer la transició a l’estat de parada. No importa on sóc i després, si amb si la transició cancel·lar l’esdeveniment, jo notifiqui als meus estudiants i després passar a l’estat de parada.
Per a les classes d’objectes que tenen una gran quantitat de comportament dinàmic, val la pena fer un diagrama d’estats per tenir una idea de tot el que ha de succeir. Pregunteu-vos què passa quan rebo un missatge? Què faig quan arribi el missatge? Què missatges que he d’enviar? Molts d’aquests missatges es converteixen en les operacions de la classe d’objecte, com en aquest exemple en què afegir un estudiant és una operació. Una gran quantitat d’aquestes accions, com l’establiment del compte, incrementant el comptador, comprovant el nombre, tots aquests es converteixen en operacions privades d’aquesta classe d’objecte particular i un diagrama d’estats és on veig això.
Com saber si vostè té una classe d’objecte dinàmic? Un cop més, tornar als diagrames de seqüència. Si vostè té una classe d’objecte que està en una gran quantitat de diagrames de seqüència i s’està fent i l’enviament d’una gran quantitat de missatges, això és una bona indicació que és una classe d’objecte bastant dinàmica i probablement hauria de tenir un diagrama d’estat per a això. També per agregacions, on es té la totalitat de les seves parts, faig un diagrama d’estat per a cada conjunt agregat. Ho faig sobretot perquè que tot agregat és sovint responsable de gestionar la missatgeria, que fa que sigui dinàmic.
diagrames de components
Per descomptat, cap sistema pot ser construït sense tenir en compte el món físic. Aquí és on entren en diagrames de components. S’utilitzen per il·lustrar les organitzacions i dependències entre els components de programari, inclosos els components de codi font, els components de temps d’execució, o un component executable. Els components són mostra com un rectangle gran amb dos rectangles més petits al costat, com es veu a la Figura 15.
Figura 15: Components
Aquestes coses rodones representen interfícies (sovint anomenat notació piruleta). En aquest cas, mostren que la register.exe depèn de les interfícies tant per al Course.dll i la People.dll. Això vol dir que si aquestes interfícies canvien, tindrà un impacte en la register.exe. Sé que hi ha aquesta regla quan hi ha la construcció d’interfícies que diu “”tu no pots canviar la interfície.”” Però ¿algú realment funciona quan s’aplica aquesta regla? Aquest diagrama ens diu el que les interfícies són utilitzats pel executables estan executant en els meus processadors.
Figura 16: Diagrama de Desplegament
L’extensió d’UML
L’última cosa que vull posar l’accent sobre l’UML és que pot ser estès. Quan es va construir l’UML, que molt sàviament es van adonar que no hi havia manera que poguessin crear una notació que podria agradar a tota la gent tot el temps. Així que ens va donar el concepte d’un estereotip. Un estereotip diu que puc prendre un element de modelatge bàsic i donar-li més significat. Els estereotips es poden usar per classificar i ampliar les associacions, les relacions d’herència, classes i components.
Figura 17: Exemple d’estereotip web
La Figura 17 mostra el diagrama dels nostres estereotips web. Una pàgina web normalment té coses que s’executa al servidor i coses que s’executa en el client. Si vostè està construint aplicacions basades en web, el que s’està executant en el client i el servidor és de vital importància. Així que tenim un conjunt d’estereotips que mostren això. Les petites rodes representen les coses que s’executen en el servidor. Així que amb només mirar a aquest diagrama puc veure el que s’executa al servidor, el que s’executa en el client, i quins objectes de negoci han de tractar.

“——————————————————————————————————————————————————

Support hubad: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”Ang UML mao ang bandila nga pinulongan alang sa espesipikong, paghanduraw, pagtukod, ug pagdokumento sa tanan nga mga karaang mga butang sa usa ka sistema sa software.””
diagram Kalihokan
Ang makataronganon nga dapit sa pagsugod sa sa paglakaw pinaagi sa sa pipila sa mga UML diagram mao ang pinaagi sa pagtan-aw sa dayagram sa kalihokan.
Figure 2: Kalihokan diagram
Kalihokan dayagram sa pagpakita sa dagan sa kontrol. Ingon sa gipakita sa Figure 2, nga kamo mahimo tan-awa ang mga kalihokan gihulagway nga rounded rektanggulo. Mga kalihokan kasagaran aksyon nag-ingon â € “”nag-ingon nga ang transisyon awtomatikong ngadto sa sunod nga kahimtang human sa aksyon mao ang bug-os nga. Ang napuno sa lingin nagrepresentar sa pagsugod sa dayagram kalihokan â € “”diin sa dagan sa pagkontrolar sa duwa. Pagbalhin gipakita ingon nga mga udyong sa pagpakita kon sa unsang paagi kamo mobalhin gikan sa kalihokan sa kalihokan. Dungan trangka sa pagpakita kon sa unsang paagi sa mga kalihokan nga mahitabo sa susama. nga ako sa pagbantay sa usa ka transisyon nga nag-ingon “”gusto ko nga moadto sa niini nga kalihokan kon niini nga kahimtang mao ang tinuod,”” ug akong ipakita kanimo diin kini pag-undang. Karon kon ikaw usa ka sa pipila ka mga edad, kamo tingali motan-aw sa niini nga diagram nga kalihokan ug maghunahuna, “”Hmm â € |. Nga motan-aw sama sa usa ka tsart dagan”” Ug nga kon unsa kini, gawas dili ko sa pagbuhat niini sa ang-ang programa. Kasagaran, sa paggamit sa ko ang usa ka kalihokan sa diagram minatarong, sa maayohon sa sayo sa akong pagtuki ug design proseso sa pagpakita sa negosyo workflow. Ako usab sa paggamit kanila sa pagpakita kon diin ang matag usa sa akong mga kaso sa paggamit mahimong sa usa ka kalihokan aron sa paghulagway kon unsa ang paggamit kaso may mahitabo. Ako usab sa paggamit sa dayagram nga kalihokan sa pagpakita kon sa unsang paagi ang mga butang modagayday sa taliwala sa akong mga kaso sa paggamit.
Apan usa sa mga dako nga mga butang mahitungod sa UML mao ang versatility. Busa samtang akong gigamit dayagram nga kalihokan sa sinugdanan sa lifecycle, ang uban mahimong mogamit kanila sa usa ka lain-laing mga hugna sa bug-os. Ako nakakita sa mga tawo nga sa paggamit sa kalihokan mga diagram sa sa ang-ang disenyo diin sila may usa ka kaayo nga komplikado nga hugpong sa mga algorithms alang sa usa ka partikular nga klase. Ug daghan ang mga tawo sa paggamit kanila sa pagpakita sa dagan sa taliwala sa mga pamaagi sa usa ka klase.
ang sistema. Aktor nga girepresentahan ingon sungkod mga numero.
Figure 4: aktor
Ang panig-ingnan nga ako nagtrabaho alang niini nga pasiuna sa UML mao ang usa ka gamay nga modelo sa usa ka sistema sa kurso registration. Busa niining higayona, ang unang butang nga akong buhaton sa diha nga ang sugod sa akong pagtuki nga proseso mao ang pagpangutana, “”nga mao ang sa makig-uban sa niini nga sistema?””
Kay ang modelo registration kurso, ako adunay usa ka registrar, usa ka propesor, ug usa ka estudyante. Ako usab usa ka eksternal nga sistema sa billing. Kini nga billing nga sistema usab nga kuwalipikado nga ingon sa usa ka aktor. (Tan-awa, ang usa ka aktor dili kinahanglan nga mahimo sa usa ka tawo â € “”kini sa bisan unsa nga interact sa mga sistema sa mga apan sa gawas sa sistema sa.)
Ang usa ka paggamit sa kaso mao ang usa ka han-ay sa mga may kalabutan nga mga transaksyon nga gihimo sa usa ka aktor sa sistema sa usa ka dialog. O, sa niini sa Iningles, usa ka paggamit kaso mao ang usa ka chunk sa kagamitan, katuyoan. Ug dinhi ang yawe: kini mao ang dili usa ka software module â € “”kini mao ang usa ka butang nga naghatag og bili sa aktor.
Paggamit mga kaso gipakita ingon nga ovals, ug ang labing sayon nga paagi sa pagpangita kanila mao ang pagtan-aw sa matag usa sa inyong mga aktor ug mangutana sa imong kaugalingon nganong gusto nila nga mogamit sa sistema. Sa akong kahimtang, ang akong tigrehistro na sa pagpadayon sa kurikulum, ang akong propesor na sa paghangyo sa usa ka line-up, ang akong estudyante sa nagmintinar sa eskedyul, ug ang akong billing nga sistema magadawat sa impormasyon billing. Busa ako sa paghimo sa akong mga kaso sa paggamit sa pagtan-aw sa niini gikan sa mga customer nga punto sa panglantaw ug sa pagpangayo, “”sa ingon, mister nga sistema aktor, nganong gusto sa paggamit sa sistema sa? Unsa ang kapuslanan niini nga sistema sa paghatag sa imo?””
Ang sunod nga lakang, sa higayon nga imong giila sa unsa nga paagi ang imong mga aktor nga pagpakig-uban sa sistema, mao buhata pagrekord sa inyong mga kaso sa paggamit. Ang matag paggamit sa kaso kinahanglan nga documented sa dagan sa mga panghitabo, ug kini gibuhat gikan sa punto sa aktor sa panglantaw. Kini kinahanglan nga detalye kon unsa ang sistema sa kinahanglan nga mohatag og sa aktor sa diha nga ang paggamit sa kaso gipatay. Kasagaran kini ipakita sa mga butang sama sa kon sa unsang paagi nga ang paggamit sa kaso magsugod ug finishes. Unsa nga mga butang ang nga ang paggamit sa kaso nga buhaton? Ikaw makabaton sa normal nga dagan sa mga panghitabo (gitawag ko ang “”malipayon nga mga adlaw”” nga situwasyon), diin ang tanan nga mga buhat. Unya inyong pagkuha sa mga abnormal nga dagan sa mga panghitabo, ang “”adlaw sa ting-ulan”” nga situwasyon. Unsay mahitabo sa diha nga ang sistema sa wala magbuhat? Ako nakit-an sa pagdokumento sa akong dagan sa mga panghitabo nga ako sa kanunay magsugod uban sa malipayon nga mga adlaw nga situwasyon.
Dad-a ingon sa usa ka panig-ingnan, nga nagalakaw sa usa ka automated teller machine. magalakaw kamo sa ATM ug sal-ot sa imong mga kard. Kini nangutana alang sa inyong PIN gidaghanon. Pagsulod ninyo, ug kamo nangutana kon unsay gusto nimong buhaton. Ikaw nag-ingon “”Gusto ko nga sa pipila ka mga salapi.”” Kini nangutana diin ang salapi kinahanglan nga gikuha gikan sa. sultihan mo kini aron sa pagkuha niini gikan sa imong pagsusi sa asoy. Kini nangutana kon sa unsang paagi sa daghan. Ikaw nag-ingon $ 100.00. Unya salamangka mahitabo â € | kini naghatag kaninyo $ 100.00. Unya kini nangutana kon gusto sa laing transaksyon. -ingon ka nga dili. Kini naghatag kaninyo sa inyong mga kard balik, naghatag kaninyo og usa ka resibo, ug ang transaksyon mao ang sa ibabaw. Mao kana ang malipayon nga adlaw nga situwasyon.
Ikaduhang situwasyon. moadto kamo sa ATM, sal-ot sa imong mga kard, ug mosulod sa imong PIN. Ang ATM nagsulti kaninyo nga kini mao ang sayop nga PIN. mo sa imong gidaghanon sa pag-usab. Pag-usab kamo gisultihan nga ang PIN sayop. Ikaw Sa akong kurso registration panig-ingnan, pananglitan, ikaw makakita nga adunay mga usa ka daghan sa “”kon X unya Y”” workflow. Nga sa diin kamo gusto nga ang imong customer nga aron sa pagtabang kanimo sa gawas. Getting kasabutan sa sayo nagpasabot nga ang imong customer nakasabot niini nga mga situwasyon ug nag-ingon “”oo, mao kini ang unsay atong gusto.”” Paggamit sa mga kaso mao ang usa ka dako nga paagi sa pagsiguro nga ang imong pagtukod mao ang tinuod nga kon unsa ang customer nga gusto, tungod kay ilang ipakita sa mga aktor, ang mga kaso sa paggamit, ug ang mga relasyon tali sa kanila.
Figure 5: Gamita ang kaso diagram
Busa kita adunay usa ka dako nga diagram nga tin nagpakita kanako sa unsa? Ang tubag mao ang yano nga â € “”kini mao ang usa ka dako nga diagram nga nagpakita sa usa ka maayo nga kinatibuk-ang pagpasabut sa sistema. Kini nagpakita kon unsa ang sa gawas sa sistema (aktor) ug ang kagamitan, katuyoan nga ang sistema sa kinahanglan sa paghatag og (mga kaso sa paggamit). Kon adunay usa ka kabilin nga sistema nga imong gikinahanglan sa pag-ngadto sa konsiderasyon, dinhi niini diin kamo atubang sa niini. Pagpugos sa ako sa pagtrabaho uban sa niini nga mga matang sa mga interface sayo kaayo sa proyekto nagpasabot nga dili ako nag-atubang uban sa paglaom nga naghulat hangtud nga coding magsugod sa numero sa kon sa unsang paagi ko nga makig-istorya ngadto sa itom nga kahon nga dili ko mahimo nga mausab ang .
Usa pa ka butang nga kamo kinahanglan nga masayud mahitungod sa mga kaso sa paggamit mao ang paggamit sa kaso katumanan. Kini mao ang “”kon sa unsang paagi”” sa paggamit sa kaso. Kini kasagaran sa usa ka balde nga naglakip sa tulo ka mga lain-laing mga matang sa dayagram: han-ay mga diagram, kolaborasyon dayagram, ug usa ka klase diyagram nga atong gitawag sa usa ka panglantaw sa pag-apil sa mga klase. Paggamit kaso kalihokan mao ang batakan sa usa ka paagi sa gihugpong sa tingub sa usa ka gidaghanon sa mga karaang mga butang nga may kalabutan sa sa disenyo sa usa ka paggamit sa kaso.
ay diagram
Ay dayagram sa pagpakita pakig butang gihan-ay sa usa ka panahon han-ay. mahimo ko sa paggamit sa dagan sa mga panghitabo aron sa pagtino kon unsa ang mga butang ug mga pakig kinahanglan ko sa pagtuman sa kagamitan, katuyoan bungat sa dagan sa mga panghitabo.
Figure 6: ay diagram
Figure 6 nagpakita kon sa unsang paagi ang usa ka estudyante sa madinalag-on nga gets dugang ngadto sa usa ka dalan. Ang estudyante (himoa nga pagtawag ni siya Joe) mipuno sa pipila sa impormasyon ug submits sa porma. porma dayon ang pakigpulong ngadto sa manager ug nag-ingon “”makadugang Joe sa Math 101.”” manager sa nagsulti Math 101 nga kini aron sa pagdugang sa usa ka estudyante. Matematika 101 nag-ingon sa Section 1 “”mga abli kanimo?”” Sa kini nga kaso, Seksyon 1 tubag nga sila bukas, mao nga Math 101 nagsulti seksyon 1 aron sa pagdugang sa estudyante niini. Pag-usab, ay dayagram ang mga dagko nga mga himan sa sinugdan tungod kay sila ipakita kanimo ug sa imong customer nga lakang-sa-lakang unsay mahitabo.
Gikan sa usa ka pagtuki nga punto sa panglantaw, akong nakita sa ibabaw sa mga tuig nga han-ay dayagram kaayo gamhanan sa pagtabang kanako sa pagpapahawa sa mga kinahanglanon; ilabi na sa mga kinahanglanon nga mga lisud nga sa pagpangita sa. mga kinahanglanon user interface, pananglitan, ang mga notoryus tungod kay kanunay kamo daw sa pagkuha sa mga kinahanglanon nga dili testable. Ang usa ka komon nga kinahanglanon UI nga sama niini mao ang “”sistema kini mao ang user-friendly.”” Sa unsang paagi nga daghan sa imong nahimamat sa usa ka mahigalaon nga computer? Usa sa mga benepisyo sa niini nga mga matang sa dayagram mao nga ang matag linya gikan sa usa ka aktor nga nagrepresentar sa usa ka tawo, nag-ingon kaninyo nga usa ka butang diha sa inyong UI adunay sa paghatag og usa ka kapabilidad nga gikinahanglan sa tawo. Sa laing mga pulong, kamo makahimo sa paggamit han-ay diagram sa pagpapahawa testable mga kinahanglanon user interface.
Ay mga diagram Busa, maayo alang sa pagpakita kon unsa ang nahitabo sa, alang sa pagpapahawa sa mga kinahanglanon, ug alang sa pagtrabaho uban sa mga kustomer. Nga kasagaran mosangpot sa pangutana, bisan, kon sa unsang paagi sa daghan nga kinahanglan nga kamo sa paghimo sa? Ang akong tubag mao ang, “”hangtud nga imong buhaton igo.”” Ikaw na sa pagpangita sa diha nga magabuhat ikaw ay dayagram nga makab-ot ang usa ka punto diin ikaw wala sa pagpangita sa bisan unsa nga bag-o nga mga butang, dili sa pagpangita sa bisan unsa nga bag-o nga mga mensahe, ug nga ikaw sa pag-type sa samang butang sa ibabaw sa ug sa ibabaw sa. Sa panig-ingnan sa Joe pagpasakop Math 101, kita makakat-on nga ang proseso nga sa mao usab nga kon Joe gusto sa pag-apil Kasaysayan 101. Busa, lagda sa kumagko, sa pagbuhat sa usa ka han-ay diyagram alang sa matag nag-unang mga dagan sa matag paggamit sa kaso. Buhata ang usa ka han-ay diyagram alang sa mga high-level, peligroso nga situwasyon, ug nga kinahanglan nga igo. Mao nga sa unsa nga paagi sa daghang mga han-ay dayagram akong buhaton.
sa paghinumdom sa dinhi, mao nga ang usa ka kolaborasyon diyagram mao ang lang sa usa ka lain-laing mga panglantaw sa usa ka situwasyon ug kamo balik ug sa taliwala sa han-ay diagram ug kolaborasyon diagram sa pagkuha sa mga panglantaw nga labing maayo nga naghulagway sa imong punto.
Usahay, mahimo mo makadungog sa hugpong sa mga pulong “”dayagram interaction.”” Usahay ang mga tawo sa kinatibuk nagtumong sa usa ka kolaborasyon diyagram ug sa usa ka han-ay diagram ingon nga usa ka interaction diagram.
Klase diagram
Usa ka klase mao ang usa ka koleksyon sa mga butang uban sa komon nga gambalay, komon nga kinaiya, komon nga mga relasyon, ug mga komon nga semantiko. makakaplag mo sila pinaagi sa pagsusi sa mga butang sa han-ay ug kolaborasyon mga diagram, ug sila nagrepresentar sa UML ingon sa usa ka rectangle uban sa tulo ka mga lawak.
Figure 8: Mga klase
Ang unang lawak nagpakita sa klase ngalan, ang ikaduha nagpakita sa iyang gambalay (mga hiyas), ug sa ikatulo nagpakita sa iyang kinaiya (operasyon). Kini nga mga lawak mahimo nga mapugngan, Apan, aron nga kamo makahimo sa pagtan-aw lang sa ngalan, lang ang ngalan ug sa mga hiyas, o sa tanan nga tulo ka mga. Usa ka butang nga kinahanglan nga kamo usab mahibalo mao nga kini importante, sa diha nga nagngalan mga klase, sa paggamit sa bokabularyo sa domain ug pick sa usa ka sumbanan. Pananglitan, ang akong mga klase ang tanan singular nombre nga magsugod uban sa usa ka kapital nga sulat. Mahimo ka nga mopili sa pagbuhat niini sa lahi nga paagi, ug nga dili igsapayan. Unsay butang mao nga sa atubangan sa inyong proyekto sa pagkuha sa usa ka sumbanan ug moipon uban niini sa ingon nga ang tanang mga butang mao ang nahisubay sa tibuok proyekto.
Klase diagram sa pagpakita kaninyo sa nagahunong kinaiya sa imong sistema. Kini nga mga diagram sa pagpakita sa pagkaanaa sa mga klase ug sa ilang mga relasyon sa mga makataronganon nga panglantaw sa usa ka sistema. Ikaw adunay daghan nga mga klase sa mga diagram diha sa usa ka modelo.
Ang mga elemento UML modelo nga makita diha sa klase dayagram naglakip sa:
Mga klase ug sa ilang mga gambalay ug kinaiya.
Association, kobransa, pagsalig, ug panulondon sa mga relasyon.
Pinilo-pilo nga ug tabok-tabok indicators
Papel ngalan.
Dad-a sa usa ka pagtan-aw sa Figure 9. diyagram nagpakita operasyon (kinaiya): unsa ang usa ka butang diha sa klase nga mahimo. nga makakaplag ako sa akong mga operasyon pinaagi sa pagtan-aw sa akong mga pakig-dayagram.
Figure 9: Operations
Ania ako sa pag-ingon nga ako kinahanglan nga makahimo sa pagpangutana sa registration manager aron sa pagdugang sa usa ka estudyante sa Math
101. Nga ni-adto sa paghubad ngadto sa usa ka operasyon nga gitawag ug “”addCourse.””
Ang gambalay sa usa ka klase nga girepresentahan sa mga hiyas niini. Busa sa unsang paagi ko sa akong mga hiyas? Pinaagi sa pagpakigsulti sa mga eksperto domain. Pinaagi sa pagtan-aw sa akong mga kinahanglanon. Sa akong panig-ingnan, makat-on ako nga ang matag kurso halad nga adunay usa ka gidaghanon, sa usa ka dapit, ug sa usa ka panahon. Kini naghubad ngadto sa tulo ka mga kinaiya.
mga klase. (Girepresentahan sa UML ingon sa usa ka linya nga nagsumpay sa mga may kalabutan sa mga klase sa usa ka diamante sunod ngadto sa klase nga nagrepresentar sa bug-os nga.)
â € ¢ Pagsalíg â € “”usa ka mahuyang nga porma nga nagpakita sa relasyon tali sa usa ka kliyente ug sa usa ka supplier diin kliyente dili semantiko kahibalo sa supplier. Ang usa ka pagsalig nag-ingon “”Kinahanglan ko ang imong mga serbisyo, apan ako wala masayud nga anaa kaninyo.”” (Girepresentahan sa UML ingon sa usa ka gipusdak linya nagtudlo gikan sa kliyente ngadto sa supplier.)
Aron sa pagpangita sa mga relasyon, sa makausa pag-usab, ako moadto sa akong ay diagram. Kon ang duha ka mga butang nga kinahanglan nga “”makig-istorya””, kinahanglan gayud nga adunay usa ka paagi sa pagbuhat sa ingon (pananglitan, usa ka relasyon tali sa ilang mga klase).
Ako kasagaran magsugod sa gawas ug sa paghimo sa tanan nga mga butang sa usa ka asosasyon. Ingon nga ako sa pagbuhat sa dugang pagtuki, aron ako makakaplag ako sa usa ka kobransa tungod kay ako moadto sa pag-atiman sa usa ka ginikanan-anak nga relasyon. Sa diha nga ako ngadto sa bahin design, makakaplag ako nga dili ako kinahanglan sa usa ka asosasyon tungod kay ang laing tawo mao ang nahitabo nga ang tumong sa usa sa akong mga pamaagi â € “”mao nga ako sa paghimo niini nga usa ka pagsalig.
Figure 11: Relasyon
Sa Figure 11 makita ninyo nga kini nga mga relasyon. Ingon sa pagpakig-nag-ingon nga ang Propesor mahimo makig-istorya sa mga Kurso halad, ug ang Kurso Halad mahimo makig-istorya sa mga Propesor. Mga mensahe mahimong gipasiugdahan ug data ang mahitabo sa bisan unsa nga direksyon. Kobransa gipakita pinaagi sa sa diamante ngadto sa tibuok nga â € “”sa niini nga kaso sa usa ka Kurso gilangkoban sa Kurso Halad. Ang rason alang sa kobransa kini sa pagsulti sa akong mga developers nga kon sila sa pagkuha Isalikway sa Kurso niini, sila tingali sa pagbuhat sa usa ka butang nga espesyal nga uban sa mga Halad Kurso. Dependencies gipakita ingon nga usa ka gipusdak nga linya. Kini nag-ingon nga ang registration manager nag-agad diha sa Eskedyul algorithm sa pagbuhat sa usa ka butang. Ang Eskedyul algorithm mao ang bisan usa ka sukaranan sa usa sa mga pamaagi o ipahayag nga lokal nga pinaagi sa usa sa mga Pamaagi sa Registration Manager.
Pinilo-pilo nga ug Navigation
Pinilo-pilo nga naghubit kon sa unsang paagi sa daghan nga mga butang apil sa usa ka relasyon. Kini mao ang gidaghanon sa mga higayon sa usa ka klase nga may kalabutan sa usa ka higayon sa laing klase. Alang sa matag asosasyon ug kobransa, adunay duha ka pinilo-pilo nga mga desisyon sa paghimo sa: ang usa alang sa matag katapusan sa relasyon. Pinilo-pilo nga gihulagway ingon nga usa ka gidaghanon ug sa usa ka * gigamit sa pagrepresentar sa usa ka pinilo-pilo nga sa daghan.
Figure 12: pinilo-pilo nga ug tabok-tabok
Usa ka Propesor Object nga may kalabutan ngadto sa zero-sa-upat ka mga Kurso Halad Butang. Usa ka Kurso Pagtanyag Tumong nga may kalabutan sa gayud sa usa ka Propesor Object. ko sa paggamit sa niini nga sa pagtan-aw sa ug sa pagsiguro nga kini handol sa akong mga kinahanglanon. Mahimo ba ako sa usa ka Kurso halad ug team-gitudlo sa usa ka hugpong sa mga propesor? Dili, tungod kay kini nag-ingon nga ako lamang usa ka propesor. Mahimo ba ako sa usa ka propesor ug sa igpapahulay? Oo, tungod kay kini nag-ingon ako sa usa ka zero kutob sa mahimo nga kurso load. ko sa paggamit sa pinilo-pilo nga sagad sa pagtabang kanako sa pagsugod pagsikop ug pagpatuman sa akong mga lagda sa negosyo. Kon kaninyo, alang sa panig-ingnan, usa ka negosyo nga pagmando nga nag-ingon nga kamo kinahanglan gayud nga adunay sa labing menos 3 estudyante ug dili labaw pa kay sa 10 alang sa usa ka dalan nga gitanyag sa usa ka semester, kini nga mga pinilo-pilo nga mga numero sa pagsulti kanako ako gilakip nga ang pagmando sa negosyo ngadto sa niini nga plano.
Tabok-tabok gipakita sa usa ka udyong, ug bisan mga asosasyon ug aggregations mga bi-direksiyon pinaagi sa remate, kini mao ang kanunay nga madanihon sa idili tabok-tabok sa usa ka direksyon. Sa diha nga tabok-tabok limitado ra, ang usa ka tumoy sa pana nga dugang pa sa nagpakita sa paglupad direksyon. Usa sa mga butang nga akong buhaton sa panahon sa pagtuki ug disenyo hugna mao ang pagtan-aw sa unsa ang akong gusto nga mahimong Uni-direksiyon. Pinaagi sa pagbutang sa udyong ngadto sa diyagram niini, ako moingon nga ang Registration Manager mahimo ipadala sa usa ka mensahe ngadto sa Kurso, tungod kay kini nahibalo sa Kurso anaa. Apan ang Kurso walay ideya nga ang registration Manager anaa, mao nga ang mga Kurso dili makahimo sa usa ka mensahe. Karon sa data ang mahitabo sa taliwala kanila; pananglitan ang Registration Manager makahangyo sa Kurso kon kini bukas ug sa Kurso makaingon nga kini mao ang. Apan lamang ang registration Manager makasugod nga panag-istoryahanay.
Tin-aw nga ang tumong dinhi mao ang pagkuha ingon nga sa daghan mga udyong samtang imong mahimo sa panahon nahuman imong pagplano, tungod kay kini usa ka daghan nga mas sayon nga sistema sa pagpadayon sa Panulondon gipakita sa usa ka triangle. Kini nagpakita nga ang mga Propesor mao ang usa ka registration User, ingon nga mao ang Estudyante. Karon, usa ka pulong sa pasidaan. Panulondon mapuslanon, bisan pa niana, ang tumong mao nga dili aron sa paggamit sa ingon sa daghan nga panulondon ingon nga imong sistema motugot. nakita ko ang pipila ka mga gayud bangis nga mga sistema diin sila may panulondon nga 17-nga lebel sa lawom nga. Kon sila nausab usa ka butang, kini nahimong usa ka katalagman. Busa ang pagmando sa kumagko mao ang sa paggamit sa panulondon lamang sa diha nga kamo tinuod gayud nga adunay usa ka panulondon sitwasyon.
State Transition diagram
Ang usa ka estado transition diyagram nagpakita sa kinabuhi sa kasaysayan sa usa ka klase. Kini nagpakita sa mga hitabo nga hinungdan sa usa ka transisyon gikan sa usa ka estado sa usa, ug ang mga buhat nga moresulta gikan sa usa ka pagbag-o sa estado.
Figure 14: State transisyon diagram
ko sa paggamit sa estado diagram transition alang sa mga klase nga butang nga kasagaran adunay usa ka daghan sa dinamikong kinaiya. button mao ang sa ibabaw sa â € | ang button mao ang sa; dili ako sa pagbuhat sa usa ka tsart nga estado alang niini. Apan butang mga klase nga adunay usa ka daghan sa dinamikong kinaiya, ako tingali moadto sa pagtan-aw ngadto sa mga estado sa mga butang.
magsugod ako sa nagpakita sa usa ka kahimtang, nga mao ang usa ka rounded triangle. makabaton ako pagsugod estado, ug ako adunay stop nag-ingon, nga gipakita ingon nga mga torong baka mata. nga ako usab nga pagbalhin sa taliwala sa mga estado, o magbalantay pagbalhin (mga butang nga mahitabo sa diha nga lamang sa diha nga ang usa ka kahimtang mao ang tinuod nga), o mga butang nga mahitabo sa diha nga ako sa sulod sa estado. motan-aw ko sa diagram ug tan-awa ang estado transition diyagram alang sa usa ka kurso nga-sinunog. Kini magsugod sa Initialization estado, ug magpabilin ako sa niana nga kahimtang hangtod nga ako usa ka “”makadugang sa estudyante”” nga mensahe. Sa diha nga ako nga mensahe nga, ibutang ko ang akong ihap sa estudyante sa zero ug ako transisyon ngadto sa Open estado. inyong tan-awa sa Figure 14 nga ako usa ka entry, ug ang rason kon nganong kini nga adunay nga ako adunay duruha ka mga paagi sa pagkuha ngadto sa estado. Kini nag-ingon nga bisan sa unsa nga paagi kamo sa estado, gusto ko nga magparehistro sa estudyante. Sa diha nga exit ko nga kahimtang, ang ihap mga kausaban sa pagbantay sa track sa sa gidaghanon sa mga estudyante sa kurso. mahimo ako sa pagdugang sa mga estudyante hangtud nga ako sa 10, ug unya ako moadto sa Close estado. Sa higayon nga ang kurso nga finalized, transisyon ako sa paghunong sa estado. Bisan diin ako unya, kon ako ang Cancel transisyon Hitabo, sa pagpahibalo sa ko sa akong mga estudyante ug dayon transisyon ngadto sa paghunong sa estado.
Kay mga klase nga butang nga adunay usa ka daghan sa dinamikong kinaiya, kini pag-ayo nga bili niini sa pagbuhat sa usa ka kahimtang dayagram sa pagkuha sa usa ka kuptanan sa tanan nga mahitabo. Pangutan-a ang imong kaugalingon kon unsa ang mahitabo sa diha nga ako usa ka mensahe? Unsa may akong buhaton sa diha nga ako sa mensahe? Unsa nga mga mensahe ngadto sa ko sa pagpadala? Ang usa ka daghan sa mga mga mensahe nga mahimong operasyon sa butang nga klase, sama sa panig-ingnan niini nga diin makadugang sa usa ka estudyante sa usa ka operasyon. Ang usa ka daghan niini nga mga aksyon, sama sa paghimo sa ihap, incrementing sa ihap, sa pagsusi sa mga ihap, kining tanan mahimo nga mga pribado nga mga operasyon sa nga partikular nga butang sa klase ug sa usa ka kahimtang diyagram mao ang dapit diin akong nakita nga.
Unsa nga paagi nga kamo nasayud nga kon ikaw adunay usa ka dinamikong nga butang nga klase? Sa higayon nga pag-usab, balik ngadto sa han-ay diagram. Kon ikaw adunay usa ka butang nga klase nga sa usa ka daghan sa han-ay diagram ug kini pagkuha ug nagpadala sa usa ka daghan sa mga mensahe, nga ang usa ka maayo nga timailhan kini sa usa ka minatarong, sa maayohon dinamikong butang sa klase ug kini kinahanglan tingali adunay usa ka tsart nga estado alang niini. Usab alang sa aggregations, diin kamo sa tibuok sa mga bahin niini, ako usa ka tsart sa estado alang sa matag kinatibuk-bug-os nga. buhaton ko kini kasagaran tungod kay hiusa tibook nga mao ang kanunay nga responsable sa pagdumala sa messaging, nga kini nga dinamikong.
component diagram
Siyempre walay sistema mahimong gitukod sa walay pagkuha sa asoy sa pisikal nga kalibotan. Nga diin component dayagram moabut sa. Sila gigamit sa paghulagway sa mga organisasyon ug mga dependencies sa taliwala sa mga sangkap sa software, lakip na ang components source code, modagan sa panahon components, o sa usa ka executable component. Components mga gipakita sa ingon sa usa ka dako nga rectangle uban sa duha ka mas gagmayng mga rektanggulo sa kilid, sama sa makita sa Figure 15.
Figure 15: Components
Kadtong round nga mga butang nagrepresentar sa mga interface (kasagaran gitawag lollipop nota). Sa kini nga kaso, ilang gipakita nga ang Register.exe nagdepende sa ibabaw sa mga interface ngadto sa mga Course.dll ug sa mga People.dll. Kana nagpasabut nga kon kini nga mga interface-usab, kini nga epekto sa Register.exe. ako nasayud nga adunay kini nga pagmando sa diha nga ikaw sa pagtukod interface nga nag-ingon “”ikaw dili mag-usab sa interface.”” Apan ang bisan kinsa sa tinuod sa trabaho diin ang lagda nga ang ipatuman? diyagram Kini nagsulti kanato kon unsa ang mga interface gigamit pinaagi sa unsa executables nagdagan sa akong processors.
Figure 16: Pagpadala diagram
gitunol UML
Ang katapusan nga butang nga gusto ko nga gibug-aton mahitungod sa UML mao nga kini nga gihatag. Sa diha nga ilang gitukod sa mga UML, sila maalamon nga nakaamgo nga walay paagi nga sila paghimo sa usa ka nota nga nagapahamuot sa tanang tawo sa katawohan sa tanan nga mga panahon. Ug gihatag nila kanato sa konsepto sa usa ka paghulagway. Ang usa ka sukdanan nag-ingon nga ako sa usa ka nag-unang mga elemento modelo ug ihatag kini sa dugang nga kahulogan. Pagtuo nawala mahimong gamiton sa pagklasipikar ug paghatag mga asosasyon, panulondon sa mga relasyon, mga klase, ug mga components.
Figure 17: Web sukdanan panig-ingnan
Figure 17 nagpakita sa dayagram sa atong Web pagtuo nawala. Ang usa ka Web panid kasagaran may putos nga midagan sa server ug sa putos nga midagan sa kliyente. Kon ikaw sa pagtukod aplikasyon Web-based, unsay nagdagan sa mga kliyente sa ug sa server mao hinungdanon. Busa kita adunay usa ka bug-os nga hugpong sa mga stereotypes, nga nagpakita nga ang. Ang gamay nga mga ligid nagrepresentar sa mga butang nga modagan sa server. Busa pinaagi sa pagtan-aw sa niini nga usa ka diagram nga ako sa pagtan-aw kon unsa ang midagan sa server, unsa midagan sa kliyente, ug unsa negosyo butang sila sa pag-atubang uban sa.

“——————————————————————————————————————————————————

Support kumasulira: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”The UML ndi chinenero muyezo malangizo, kuona, kumanga, ndi Kulemba zinthu zakale zonse za dongosolo mapulogalamu.””
ntchito Zithunzi
Malo zomveka kuyamba kuyenda ena mwa zithunzi za UML ndi kuyang’ana pa zithunzi ntchito.
Chithunzi 2: Ntchito chithunzi
Ntchito zithunzi kusonyeza otaya kulamulira. Monga taphunzira Chithunzi 2, inu mukhoza kuwona zinthu ankayimiridwa ngati rectangles anamaliza. Activities chimakhala kanthu limati â € “”limanena kuti kusintha basi kuti boma mwake kanthu chokwanira. The wodzazidwa bwalo akuimira chiyambi cha chithunzi ntchito â € “”pamene otaya ulamuliro ayamba. Kusintha akuonetsedwa ngati mivi mmene kusamukira ku ntchito kuti ntchito. Kalunzanitsidwe mipiringidzo kusonyeza mmene zinthu zikuchitika mu kufanana. I zikhoza kutithandiza kuteteza kusintha kuti anati “”Ine ndikufuna iwe upite ntchito ngati chikhalidwe ichi ndi choona,”” ndipo ine ndikuwonetseni inu kumene izo zimaleka. Tsopano ngati inu muli msinkhu winawake, inu mwina kuyang’ana pa chithunzi ichi ntchito ndi kuganiza, “”Ayi â € |. Owoneka ngati otaya tchati”” Ndipo ndicho chimodzimodzi chimene icho chiri, koma ine sindiri kuchita izo pansi pa mlingo mapulogalamu. Childs, I ntchito ntchito chithunzi mwachilungamo oyambirira mu kusanthula ndi mamangidwe wanga ndondomeko kusonyeza malonda mayendedwe. Ine ntchito iwo kusonyeza aliyense wa ntchito milandu anga akakhale ntchito kufotokoza zimene ntchito nkhani ziyenera kuchitika. I ntchito ntchito zithunzi kusonyeza mmene zinthu ikuyenda pakati pa ntchito milandu wanga.
Koma chimodzi cha zinthu zopambana za UML ndi amagwiritsidwa ntchito mwanjira zosiyanasiyana. Choncho pamene ine ntchito ntchito zithunzi kumayambiriro kwa lifecycle, ena amazigwiritsa ntchito mu gawo zosiyana kwathunthu. Ine ndaonapo anthu ntchito ntchito zithunzi pansi pa mlingo kapangidwe kumene iwo anali yovuta kwambiri ya ma aligorivimu kalasi ina. Ndipo anthu ambiri ntchito kusonyeza otaya pakati pa njira kalasi.
dongosolo. Zisudzo akuchitira kanjedza ndodo.
Chithunzi 4: zisudzo
chitsanzo chimene ine ntchito kwa oyamba izi kwa UML ndi chitsanzo chaching’ono cha dongosolo Inde kulembetsa. Choncho pa nthawiyi, chinthu choyamba chimene ine ndikufuna kuchita poyambitsa kusanthula njira yanga ndi kufunsa, “”yemwe ati kucheza ndi dongosolo?””
Pakuti njira kalembera chitsanzo, ine ndi kaundula, pulofesa, ndi wophunzira. Inenso ndi dongosolo kunja zolipiritsa. dongosolo zolipiritsa komanso wavomerezedwa kukhala wosewera ndi. (Onani, wosewera ndi alibe kukhala munthu â € “”ndi chirichonse chimene interacts ndi dongosolo koma kunja kwa dongosolo.)
A choncho ntchito ndi ndondomeko ya wotuluka okhudzana anachita ndi wosewera mu dongosolo mu kukambirana a. Kapena, kuika mu English, ntchito nkhani ndi chipika wa magwiridwe. Ndipo apa pali kiyi: si mapulogalamu gawo â € “”ndi chinthu chimene amapereka kufunika kwa wosewera wa.
Ntchito Nthawi amaoneka ngati ovals, ndi chophweka njira kuwapeza ndi kuyang’ana aliyense wa ochita wanu ndi dzifunseni kuti n’chifukwa chiyani mukufuna kugwiritsa ntchito dongosolo. Lakuti, kaundula wanga ati kukhala sukulu, pulofesa ati kuitanitsa rositala, wophunzira anga amakhala yake, ndi dongosolo wanga zolipiritsa amalandira mauthenga zolipiritsa. Kotero ine analenga milandu ntchito anga ndi kuyang’ana pa izo mfundo makasitomala bwanji kufunsa, “”choncho, bambo dongosolo wosewera, n’chifukwa chiyani mukufuna kugwiritsa ntchito dongosolo? Kodi phindu Kodi dongosolo kupereka kwa inu?””
Chotsatira, kamodzi inu mwazindikira momwe zisudzo kwanu zimavuta ndi dongosolo, kodi kulembamo milandu ntchito yanu. Iliyonse ntchito ayenera zalembedwa mgwirizano wa zinthu, ndipo zimenezi ndi mfundo za wosewera amazionera. Tiyenera tsatanetsatane zimene dongosolo ayenera kupereka kwa wosewera pamene choncho chimagwiritsidwa ntchito anaphedwa. Childs chikaonekera zinthu monga momwe ntchito nkhani akuyamba ndi akumaliza. zinthu kodi choncho ntchito ndi kuchita? Inu ndi otaya yachibadwa zochitika (chimene ine timawutcha “”masiku osangalatsa”” zochitika), kumene chirichonse ntchito. Ndiye inu mudzapeza otaya nthenda ya zinthu, ndi “”mvula tsiku”” zochitika. Kodi chikuchitika n’chiyani pamene dongosolo sachiza? Ndapeza ndi Kulemba otaya wanga zochitika zimene ine nthawizonse timayamba ndi masiku wosangalala zochitika.
Tengani chitsanzo, akuyenda kwa wonena makina makina. Muyenda ndi ATM ndi kumanga khadi lanu. Akufunsa kuti Pin nambala yanu. Mukalowamo, ndipo mwapemphedwa zimene mukufuna kuchita. Inu mukuti, “”Ine ndikufuna ndalama.”” Akufunsa kumene ndalama ayenera kuchotsedwa. Inu kuuza muzitenge pa nkhani yanu kuona. Akufunsa mmene. Inu mukuti $ 100,00. Ndiye matsenga zimachitika â € | kumakupatsani $ 100,00. Ndiye akufunsa ngati mukufuna kugula wina. Inu mukuti ayi. Iwo amakupatsani inu khadi lako, kumakupatsani chiphaso, ndipo iwowo yatha. Ndicho wachimwemwe tsiku zochitika.
Chachiwiri zochitika. Upita ku ATM, amaika khadi lanu, ndi kulowa Pin wanu. The ATM akukuuzani ndi Pin cholakwika. Inu kulowa nambala yanu kachiwiri. Kachiwiri amauzidwa kuti Pin sizolondola. Inu Mu njira yanga kalembera chitsanzo Mwachitsanzo, mukhoza kuona kuti pali zambiri “”ngati X ndiye Y”” workflows. Ndiko kumene mukufuna makasitomala anu kuti kunja. Kupeza mgwirizano oyambirira amatanthauza kasitomala wanu amadziwa zochitika zimenezi ndipo akuti “”inde, izi ndi zimene tikufuna.”” Ntchito milandu ndi njira kuonetsetsa kuti zimene inu kumanga kwenikweni zimene kasitomala akufuna, chifukwa kuonetsa zisudzo, milandu ntchito, ndipo ubale wa pakati pawo.
Chithunzi 5: Gwiritsani ntchito nkhani chithunzi
Chotero tiyenera chithunzi chachikulu zimene zimaonetsa Zimasonyeza chiyani? Yankho lake ndi losavuta â € “”ndi chithunzi chachikulu chimene chikusonyeza mwachidule wabwino wa dongosolo. Limafotokoza zimene kunja dongosolo (zisudzo) ndi magwiridwe kuti dongosolo ayenera kupereka (ntchito milandu). Ngati pali dongosolo cholowa muyenera kuganizira, apa ndi pamene inu kuchita. Kukakamiza ine kugwira ntchito ndi mitundu ya polumikizira m’banda polojekiti zikutanthauza kuti sindidzakhala ndi anakumana ndi chiyembekezo kudikira wolemba pulogalamu kumayamba kuti muganize momwe ine nditi ndiyankhule kwa bokosi wakuda kuti sindingathe kusintha .
chinthu chimodzi zambiri muyenera kudziwa za milandu ntchito ndi ntchito nkhani kuzindikira. Ichi ndi “”mmene”” ntchito nkhani. Ndi kawirikawiri chidebe kuti muli mitundu itatu yosiyanasiyana ya zithunzi: zinayendera zithunzi, zithunzi mgwirizano, ndi gulu chithunzi chimene ife timachitcha view magulu nawo. Ntchito kuzindikira nkhani kulemerako njira grouping pamodzi zingapo zakale zokhudza kamangidwe ka ntchito mlandu.
zinayendera Zithunzi
Zinayendera zithunzi kusonyeza chinthu ankachita anakonza mu ndondomeko nthawi. I kugwiritsa ntchito otaya zinthu kudziwa zinthu ndiponso zimene ankachita I ayenera kukwaniritsa magwiridwe mwachindunji ndi nthenda zochitika.
Chithunzi 6: zinayendera chithunzi
Chithunzi 6 ikusonyeza mmene wophunzira bwino kamakhala anawonjezera kuti ndithudi a. wophunzirayo (tiyeni amamutcha Joe) likukwaniritsa mu zinthu zina ndipo amagonjera mawonekedwe. mawonekedwe ndiye analankhula ndi bwana ndipo anati “”kuwonjezera Joe kuti masamu 101.”” bwana limatiuza masamu 101 kuti ayenera kuwonjezera wophunzira. Masamu 101 anati kwa Gawo 1 “”mumatsegula?”” Pankhaniyi, Gawo 1 mayankho amene ali lotseguka, kotero masamu 101 limatiuza Chigawo 1 kuwonjezera wophunzira. Kachiwiri, ndondomeko zithunzi ndi zida chachikulu pachiyambi chifukwa akupatsa ndi kasitomala wanu tsatane-tsatane zimene ziyenera kuchitika.
Kuchokera kusanthula maganizo, Ndapeza zaka kuti ndondomeko zithunzi ndi zamphamvu kwambiri pothandiza ine galimoto amafuna; makamaka amafuna kuti ndi kuchipeza. Wosuta mawonekedwe amafuna Mwachitsanzo, oipa chifukwa inu nthawizonse kuoneka ngati amafuna kuti basi osati testable. A UI lamulo wamba monga chonchi ndi “”dongosolo adzakhala wosuta-wochezeka.”” Ndi angati a inu anakumana ndi kompyuta wochezeka? Ubwino umodzi wa mitundu ya zithunzi lililonse mzere akubwera kuchokera wosewera loimira munthu, akukuuzani kuti chinachake mu UI wanu kupereka mphamvu anafunika mwa munthuyo. M’mawu ena, mungathe kugwiritsa ndondomeko zithunzi wotulutsa testable amafuna wosuta mawonekedwe.
Zinayendera zithunzi ndi Choncho, zabwino posonyeza zimene zikuchitika, poyendetsa malangizo, ndi ntchito ndi makasitomala. Kuti kawirikawiri zimabweretsa funso bwanji za angati muyenera kulenga? Yankho wanga, “”mpaka inu kuchita mokwanira.”” Inu tipeza pamene inu muchita zinayendera zithunzi kuti inu mufika pamlingo limene inu simuli kupeza zinthu zatsopano, osati kupeza mauthenga zatsopano, ndipo inu mukulemba chinthu chomwecho mobwereza bwereza. Mu chitsanzo cha Joe kujowina masamu 101, tikuphunzira kuti ndondomeko adzakhala chimodzimodzi ngati Joe ankafuna kuti agwirizane History 101. Choncho, ulamuliro wa chala, kodi zinayendera chithunzi iliyonse otaya kunayambitsa nkhani iliyonse ntchito. Kodi zinayendera chithunzi cha pamwamba pa nkhani zoopsa, ndiponso kuti akhale mokwanira. Ndicho angati ndondomeko zithunzi ndichita.
kukumbukira pano, ndi kuti mgwirizano chithunzi chabe ndi maganizo osiyana a zochitika ndi inu mukhoza kupita mmbuyo ndi mtsogolo pakati pa zithunzi ndondomeko ndi zithunzi mgwirizano kuona kuti bwino zikutsindika mfundo zanu.
Nthawi zina mukhoza kumva mawu akuti “”mogwirizana zithunzi.”” Nthawi zina anthu pamodzi kutanthauza mgwirizano chithunzi ndi ndondomeko chithunzi monga chithunzi mogwirizana.
Maphunziro Zithunzi
m’kalasi ndi mndandanda wa zinthu ndi dongosolo wamba, khalidwe wamba, mabwenzi wamba, ndi manenedwe wamba. Munawapeza ndi kufufuza zinthu mwa ndondomeko ndi mgwirizano zithunzi, ndipo iwo amakhala mu UML monga rectangle ndi zipinda zitatu.
Chithunzi 8: Makalasi
Chipinda choyamba limasonyeza dzina kalasi, wachiwiri limasonyeza dongosolo lake (makhalidwe), ndi lachitatu zikusonyeza makhalidwe ake (ntchito). makontena zikhoza kuletsedwa Komabe, kuti inu kuona dzina, monga dzina ndi zikhumbo, kapena onse atatu. chinthu chimodzi muyenera kudziwa kuti ndi zofunika, pamene anangotchula makalasi, kugwiritsa ntchito mawu a ulamuliro ndi kutenga muyezo. Mwachitsanzo izi, makalasi anga onse manauni mmodzi kuti kuyamba ndi likulu kalata. Mungasankhe kuchita mosiyana ndi zimenezo zilibe. Kodi nkhaniyi ndi kuti pamaso pa polojekiti mutapeza muyezo ndi kum’mamatira, kotero kuti zonse mogwirizana kudutsa polojekiti.
Maphunziro Zithunzi ndikusonyezeni inu chikhalidwe malo amodzi a dongosolo wanu. zithunzi izi zikusonyeza kuti kuli makalasi ndi mgwirizano mu view zomveka a dongosolo. Mudzakhala ndi zithunzi zambiri kalasi mu chitsanzo.
Zinthu UML mawerengeredwe opezeka zithunzi gulu monga:
Makalasi ndi dongosolo lawo ndi khalidwe.
Association, loitanirana, kudalira anthu ena, ndi cholowa mabwenzi.
Multiplicity ndi navigation zizindikiro
Ntchito maina.
Tione Chithunzi 9. Chithunzichi chikusonyeza ntchito (makhalidwe): kodi chinthu m’kalasi kuti angachite. Ndimaona ntchito yanga poona ankachita wanga zithunzi.
Chithunzi 9: Ntchito
Pano ine ndikunena kuti ndikufunika mungathe kufunsa woyang’anira kalembera kuwonjezera wophunzira masamu
101. Zimenezo ati lakuti ntchito yotchedwa “”addCourse.””
Kapangidwe ka gulu ukufanizidwa ndi zotsatira zake. Choncho kodi ndimaona makhalidwe anga? Mwa kuyankhula kwa akatswiri ankalamulira. Ndi kuyang’ana pa malamulo anga. Mwa ine, ine chiyani kuti aliyense nsembe Inde angapo, malo, ndi nthawi. Izi anamasuliridwa kuti makhalidwe atatu.
makalasi. (Womwe mu UML monga mzere kulumikiza magulu ena ofanana ndi daimondi pafupi ndi gulu woimira wonse.)
â € ¢ kudalira â € “”chofooka mawonekedwe kusonyeza ubale ndi kasitomala ndi katundu kumene kasitomala sadziwa zamalankhulidwe ya katundu wa. wodalira akuti “”Ndikufuna chithandizo chanu, koma ine sindikudziwa kuti muliko.”” (Womwe mu UML monga mzere kumugwetsera kulozera kwa kasitomala kwa katundu wa.)
Kupeza mabwenzi, kamodzinso, ine kubwerera ndondomeko chithunzi changa. Ngati zinthu ziwiri ayenera “”kulankhula””, payenera kukhala njira kutero (i.e., ubale pakati pa magulu awo).
I ambiri kuyamba ndi chirichonse limodzi. Monga ine ndikuchita kusanthula kwambiri, ine ndikhoza kupeza Ndili loitanirana chifukwa ine ndikuti kusamalira ubale wa kholo ndi mwana. Pamene ine ndilowe mu gawo kamangidwe, ine ndapeza kuti ndisakhale ayenera bungwe chifukwa winawake ati pochitika kuti chinthu ku imodzi mwa njira yanga â € “”kotero Ndimaonetsetsa kuti wodalira.
Chithunzi 11: Ubale
Chithunzi 11 mukuona maubwenzi amenewa. Monga kucheza ati Professor akhoza kuyankhula kwa Ndithudi Chopereka, ndi Ndithudi Chopereka akhoza kuyankhula kwa Professor. Mauthenga akhoza kuyamba ndi deta akhoza kuyenda njira iliyonse. Loitanirana Titha kukhala ndi diamondi kwa onse â € “”Pankhaniyi Ndithudi zili ndi wa Nsembe Ndithudi. Chifukwa loitanirana izi kuuza kutukula anga kuti ngati kuchotsa izi, iwo mwina chinthu chinachake chapadera ndi nsembe Ndithudi. Dependencies amaoneka ngati mzere sizinachitike. Iwo akunena kuti bwana kalembera kumadalira aligorivimu ndi Ndandanda kuchita chinachake. The aligorivimu Ndandanda mwina ndi chizindikiro kuti imodzi mwa njira kapena amayesedwa kwanuko ndi mmodzi wa Njira Manager chonse.
Multiplicity ndi Navigation
Multiplicity liri kutanthauzira mmene zinthu zambiri nawo ubwenzi. Ndi chiwerengero cha nthawi ya gulu limodzi zokhudzana Mwachitsanzo mmodzi wa kalasi ina. Lililonse kucheza ndi loitanirana, pali Zigamulo ziwiri multiplicity kuti: aliyense mapeto a ubwenzi. Multiplicity ankayimiridwa ngati zingapo ndipo * ndi ntchito kuimira multiplicity ambiri.
Chithunzi 12: Multiplicity ndi navigation
Mmodzi Professor chinthu likugwirizana zero ndi anayi Ndithudi Chopereka Zinthu. Ndithudi wopeleka chinthu likugwirizana ndendende wina Professor chinthu. I ntchito kuyang’ana ndi kuonetsetsa kuti uyu amangomvera zofunika. Ndingadziwe Ndithudi nsembe ndi gulu anaphunzitsa ndi gulu la aphunzitsi? No, chifukwa akuti Ine angathe pulofesa wina. Ndingadziwe pulofesa ndi kukhala pa Sabata? Inde, chifukwa akuti ndili ndi zero kotheka Inde katundu. I ntchito multiplicity nthawi zambiri kundithandiza kuyamba wogonjetsa ndikukhazikitsa malamulo ntchito yanga. Ngati muli Mwachitsanzo, bizinesi ulamuliro amene amati inu muyenera kukhala ophunzira pafupifupi 3 ndi zosaposa 10 N’zoona kuti iperekedwe teremu kuti chiwerengero multiplicity kundiuza ine kuwonjezekeredwa kuti ntchito ulamuliro mu dongosolo.
Navigation kukuonetsedwa muvi, ndipo ngakhale kugwirizana ndi aggregations ndi zina kuti adzipeza mbali zotsatira, nthawi zambiri zofunika kuchepetsa navigation malangizo mmodzi. Pamene navigation ali womangika, ndi arrowhead anawonjezera kusonyeza malangizo panyanja. Chimodzi mwa zinthu ndichita pa kusanthula ndi mamangidwe mbali ndi kuyang’ana pa chimene ine ndikufuna kuti uni mbali. Tikavala muvi mu chithunzi ichi, ndinena kuti Manager Kulembetsa akhoza kutumiza uthenga kwa Ndithudi, chifukwa amadziwa Ndithudi alipo. Koma Ndithudi alibe maganizo amene Manager Kulembetsa alipo, kotero Ndithudi sangakhoze kuyambitsa uthenga. Tsopano deta akhoza kuyenda pakati pawo; Mwachitsanzo ya Manager Kulembetsa angapemphe Ndithudi ngati kuli wotseguka ndipo Ndithudi anganene kuti. Koma Manager Kulembetsa mukhoza kuyamba kukambirana.
Mwachionekere cholinga pano ndi kutenga mivi ambiri momwe mukhoza ndi nthawi inu anamaliza mapulani, chifukwa ndi dongosolo zosavuta kukhala Madalitso zikusonyezedwa ndi kansalu a. Izi zikusonyeza kuti Professor ndi Kulembetsa Wosuta, monga Student. Tsopano, mawu chenjezo. Cholowa lipindulitsa Komabe, cholinga kuti ntchito cholowa mmene dongosolo anu adzalola. Ine ndawonapo ena machitidwe kwenikweni mwankhanza kumene iwo anali cholowa 17 misinkhu kwambiri. Ngati iwo anasintha zinthu zina, iwo anakhala tsoka. Choncho ulamuliro wa chala chachikulu ndi ntchito cholowa kokha pamene inu moona nawo cholowa zinthu.
State Zidziwitso Zithunzi
A chithunzi boma kusintha amasonyeza mbiri ya moyo wa gulu anapatsidwa. Izo zimasonyeza zinthu zimene zimachititsa kusinthika kuchokera ku boma wina ndi mzake, ndi zochita chifukwa kusintha boma.
Chithunzi 14: State kusintha chithunzi
I ntchito boma kusintha zithunzi makalasi zinthu zambiri ndi zambiri khalidwe zazikulu. Batani pa € â | batani ZACHOKA; Ine sinditi kuchita boma tchati izo. Koma chinthu maphunziro amene zambiri khalidwe zazikulu, ine mwina ndiyenera kuti aone madera a zinthu.
I kuyamba ndi kuwonetsa chikhalidwe, chomwe chiri anamaliza kansalu. Ine ndikhoza kukhala chiyambi limati, ndipo ine akhoza kuletsa limati, amene amaoneka ngati ng’ombe maso. I akhozanso kusintha pakati pa mayiko, kapena kusintha chenjerani (zinthu kuti zichitike zokha pamene chikhalidwe ndi oona), kapena zinthu kuti zichitike pamene ine ndiri mkati boma. Ine ndimayang’ana pa chithunzi ichi ndi kuona boma kusintha chithunzi cha nsembe ndithudi. Zikuyamba mu boma initialization, ndipo ine ndimakhala ku boma kuti panopa ndi “”kuwonjezera wophunzira”” uthenga. Ndikadzafika uthenga kuti, ndakupatsani achiyesa wanga wa wophunzira zero ndi ine kusintha kwa boma Open. Inu muwona Chithunzi 14 kuti ndili kulowa, ndipo chifukwa chake ndi ichi Ine ndi njira ziwiri za kulowa dziko. Limanena kuti kaya inu kulowa boma, ine ndikufuna inu kulembetsa wophunzirayo. Pamene ine kutuluka akuti, kusintha achiyesa kukhala ndi njira yolongosoka chiwerengero cha ana mu maphunzirowa. Ine ndikhoza kupitiriza kuwonjezera ophunzira panopa mpaka 10, ndipo ndimuka kwa boma Close. Kamodzi Maphunzirowa kuimaliza kukonza, ine kusintha kwa boma siteji. Kulikonse kumene ine ndiri, ngati ine kupeza Kuletsa Chochitika kusintha, ine awadziwitse ophunzira anga ndiyeno kusintha kwa boma siteji.
Makalasi zinthu zambiri khalidwe zazikulu, ndi bwino kupita kuchita boma chithunzi kupeza chogwirira pa zonse zimene ziyenera kuchitika. Dzifunseni chimene chimachitika pamene ine ndikafika uthenga? Kodi ndimatani ndikadzafika uthenga? Kodi mauthenga ine kutumiza? A zambiri mauthenga amene anakhala ntchito ya gulu la chinthu, monga chitsanzo kumene kuwonjezera wophunzira ndi opareshoni. A zambiri zimenezi, ngati akhala kuwerenga anthu incrementing kuwerenga anthu kuona kuwerenga anthu awa onse ntchito payekha gulu makamaka chinthu ndi boma chithunzi ndi pamene ndikuona kuti.
Kodi mukudziwa ngati muli ndi zazikulu chinthu kalasi? Apanso, kubwerera zithunzi zinayendera. Ngati muli ndi chinthu gulu ziri zambiri zithunzi ndondomeko ndi tikufika ndi kutumiza zambiri mauthenga, ndizo zimasonyeza ndi mwachilungamo zazikulu chinthu kalasi ndipo ayenera mwina ndi boma tchati izo. Komanso aggregations, kumene muli monse ziwalo, ndichita boma tchati iliyonse lonse akaphatikiza. Ine kuchita makamaka chifukwa akaphatikiza lonse nthawi zambiri kutsogolela za kayendesedwe ka mauthenga, zomwe zimachititsa kuti zazikulu.
zithunzi chigawo chimodzi
Kumene palibe dongosolo akhoza kumangidwa popanda kutenga nkhani dziko thupi. Ndiko kumene zithunzi chigawo kubwera. Iwo pofotokoza mabungwe ndi dependencies mwa zigawo mapulogalamu, kuphatikizapo zigawo gwero code, kuthamanga zikuluzikulu nthawi, kapena chigawo executable. Zigawo ndi mapulogalamu monga rectangle lalikulu ndi rectangles awiri ang’onoang’ono kumbali, malinga Chithunzi 15.
Chithunzi 15: Zigawo
zinthu kuzungulira kuimira polumikizira (zambiri amatchedwa lollipop kalembedwe). Pankhaniyi, amasonyeza kuti Register.exe kumadalira polumikizira kwa Course.dll ndiponso People.dll. Zikutanthauza ngati polumikizira izi zisinthe, izo kusintha mu Register.exe. Ndikudziwa kuti pali lamulo limeneli pamene inu kumanga polumikizira kuti akuti “”iwe sasintha mawonekedwe.”” Koma aliyense makamaka ntchito kumene ulamuliro umene kukakamizidwa? Chithunzichi limatiuza zimene polumikizira ntchito zimene executables akuthamanga pa mapurosesa wanga.
Chithunzi 16: Kutumizidwa chithunzi
Kuwawonjezera UML
Chinthu chotsiriza ine ndikufuna kutsindika za UML ndi kuti angathe. Pamene iwo anamanga UML, iwo mwanzeru kwambiri anazindikira kuti panalibe njira iwo akanakhoza kulenga kalembedwe kuti akhoza kusangalatsa onse a anthu onse a nthawi. Choncho anatipatsa mfundo stereotype a. stereotype A anati ine ndikhoza kutenga mfundo mawerengeredwe amafotokozera ndi kuupereka waphindu. Olakwika ingagwiritsidwe ntchito m’kagulu ndi zokulitsa mayanjano, mabwenzi cholowa, makalasi, ndi mbali.
Chithunzi 17: Web stereotype Mwachitsanzo
Chithunzi 17 limasonyeza chithunzi cha Web olakwika wathu. A Intaneti ambiri ali zinthu amayendera makina ndi zinthu zimene amayendera kasitomala. Ngati inu kumanga ntchito Web ofotokoza zimene akupikisana pa kasitomala ndi makina n’zofunika kwambiri. Chotero tiyenera lonse ya olakwika amene amasonyeza kuti. Magudumu aang’ono kuimira zinthu kuthamanga pa makina. Choncho monga mwa kuyang’ana chithunzi uyu Ndikuona zimene amayendera makina, zomwe amayendera kasitomala, nanga ntchito zinthu zimene kuthana ndi.

“——————————————————————————————————————————————————

支持翻译:http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“该UML是指定,可视化,构造和文档软件系统的所有工件的标准语言。”
活动图
开始通过一些UML图走的逻辑位置是看活动图。
图2:活动图
活动图显示控制流。如图2中所示,可以看到表示为圆角矩形活动。活动通常动作状态€“指出自动过渡到下一个状态的动作完成之后。该填充圆表示活动图的开始€“,其中控制开始流动。用箭头表示视线告诉你如何摆脱因活动。同步栏显示活动并行是如何发生的。我可以防守,说一个过渡“我要你去仅当此条件为真这个活动,”我可以告诉你在哪里停止。现在,如果你是一个一定的年龄,你可能会看到这个活动图,并认为,“嗯â€|看起来像一个流程图”。而这正是它是什么,但我不这样做下来的编程水平。通常情况下,我很早就上使用我的分析和设计过程的活动图显示业务流程。我也将用它们来显示每个我的用例可能是一个活动来说明用例有发生。我还用活动图显示的东西我用例之间如何流动。
但关于UML的伟大的事情之一是它的多功能性。所以,当我在生命周期的初期使用活动图,其他人完全可以在不同的阶段使用它们。我见过的人使用的活动在设计水平,他们有一个非常复杂的算法集为特定的类图了。而很多人用它来显示一个类的方法之间的流动。
系统。演员表示为坚持数字。
图4:演员
我的工作弥补了这一介绍UML的例子是一个课程注册系统的小模型。因此,在这种情况下,第一件事我就开始我的分析过程是问,什么时候“谁去与该系统进行交互?”
对于课程注册模式,我有一个登记处,一位教授和学生。我也有一个外部计费系统。该计费系统也有资格作为一个演员。 (参见,演员不必是一个人€“是任何与系统交互,但是该系统的外面。)
用例是由演员在系统中的对话进行关联交易的序列。或者,把它的英文,一个用例是功能性的块。而这里的关键:它不是一个软件模块A€“这是东西,提供价值的演员。
用例显示为椭圆形,并找到他们最简单的方法是看每个演员,问自己为什么他们要使用的系统。就我而言,我的注册商是要保持的课程,我的教授会要求名册,我的学生保持时间表,和我的计费系统收到计费信息。所以,我从客户的角度看它,并要求,创建我的用例“,所以,老总系统参与者,你为什么要使用这个系统?什么样的价值为什么这个系统提供给你?”
下一步,一旦你已经确定你是如何将演员与系统进行交互,是做记录您的用例。每个用例需要与事件流进行记录,这是从看演员的点完成。它应详细说一下系统必须执行用例时,提供给演员。通常情况下,它会显示之类的东西用例是如何开始和结束。这是否用例有什么事情要做?你必须在正常事件的流程(我称之为“幸福的日子”的情况),这里的一切工作。然后你会得到事件的异常流量,在“未雨绸缪”的情景。当系统无法正常工作,会发生什么?我已经通过我的记录,我总是与快乐的日子方案开始的事件流中。
采取作为一个例子,走到自动取款机。您步行到ATM和插入你的卡。它要求你的PIN码。你走进它,并询问您想做些什么。你说“我想要一些钱。”它要求这些钱应该服用。你告诉它把它从你的支票账户。它要求有多大。你说的$ 100,00。然后,奇迹发生了â€|它给你$ 100,00。然后,它会询问您是否另一个事务。你说没有。它给你的卡的背面,给你一张收据,交易结束。这就是快乐的日子场景。
第二个场景。你去到ATM,插入卡,并输入PIN码。在ATM告诉您这是错误的PIN。您再次输入您的电话号码。同样,你被告知的密码不正确。你在我的课程注册的例子,比如,你可以看到,有很多的“如果X,则Y”的工作流程。这就是你希望你的客户来帮助你。获取协议早期意味着你的客户了解这些方案并说:“是的,这就是我们想要的。”用例是要确保你正在构建真的是客户需要什么的好方法,因为它们显示的演员,用例,以及它们之间的关系。
图5:用例图
因此,我们有一个伟大的图,它以图形方式显示我什么?答案很简单€“这是一个伟大的图,它显示了系统的一个很好的概述。它显示的是在系统(演员),并且系统必须提供(使用例)的功能之外。如果你需要考虑到一个遗留系统,这里就是你对付它。迫使我与这些类型的接口工作在项目很早意味着我不会面临着等到开始编码的前景弄清楚如何我要谈给黑盒子,我不能改变。
你应该知道的使用案例一件事是用例的实现。这是“如何”的使用情况。它通常包含三种不同类型的图一斗:序列图,协作图,而我们所说的参与类的视图类图。用例实现基本都组合在一起了许多与用例设计文物的一种方式。
序列图
序列图显示安排在一个时间序列对象交互。我可以使用的事件流,以确定哪些对象和交互我将需要完成由事件流中指定的功能。
图6:序列图
图6示出了如何一个学生成功被添加到一个疗程。学生(让我们称他为乔)填写一些信息并提交表单。该表格随后会谈到经理,并说“添加乔数学101”经理告诉数学101,它具有增加的学生。数学101说,第1节“你开?”在这种情况下,第1条回复,他们是开放的,所以数学101告诉节1添加这个学生。同样,序列图是伟大的工具,在开始的时候,因为他们表现出你和你的客户一步一步有什么发生。
从一个角度分析来看,我发现这些年来序列图是在帮助我推动的需求非常强大的;特别是要求,是很难找到的。用户界面的要求,比如,是臭名昭著,因为你总是能得到只是不可测试的要求。像这样的常见的UI要求是“这个系统应是用户友好的。”你们有多少人见过一个友好的电脑吗?其中的一个类型的图的好处是,从代表一个人的演员来的每一行,告诉你的东西在你的UI必须提供由该人所需要的能力。换句话说,你可以使用序列图来驱除测试的用户界面需求。
序列图,因此,很好的显示是怎么回事,驱动了需求,并与客户合作。这通常会导致问题,但是,做多少你需要创建?我的回答是,“直到你做的不够。”你会发现当你做,你达到一个地步,你不会找到任何新的对象,没有找到任何新信息序列图,并且,你一遍又一遍地输入同样的事情。在乔加盟数学101的例子中,我们了解到,这个过程将是相同的,如果乔想加入历史101.因此,经验法则,对于每个用例的每一个基本流程做一个序列图。做为高级别,有风险的情况下的序列图,而应该是足够的。这就是我多少序列图做到。
要记住,是一个协作图是场景的只是不同的看法,你可以来回走顺序图和协作图之间获得最能阐明你的观点的看法。
有时,你可能会听到“交互图”。有时人们将统称协作图和交互图的序列图。
类图
一类是具有共同结构,共同行为,共同关系和共同语义对象的集合。你通过检查序列和协作图中的对象找到它们,并且它们在UML作为具有三个隔室的矩形表示。
图8:类
第一个参数说明类名,第二个显示出其结构(属性),而第三个显示其行为(操作)。这些车厢可以抑制然而,这样您就可以看到刚才的名字,只是名称和属性,或全部三个。有一件事你还应该知道的是,这一点很重要,命名类时,使用领域的词汇和挑选的标准。对于这种情况下,我的课都是以大写字母开头的单数名词。您可以选择以不同的方式做到这一点,那没关系。什么事做的是,你选择一个标准,并坚持下去,使一切是整个项目一致的项目之前。
类图显示您的系统的静态特性。这些图显示的类及其中的系统的逻辑视图的关系的存在。你将有一个模型中的许多类图。
在类图中找到的UML建模元素包括:
类和它们的结构和行为。
协会,聚集,依赖和继承关系。
多重性和导航指示
角色名称。
看看图9.此图显示了操作(行为):在该类的对象可以做什么。我通过看我的交互图找到我的操作。
图9:操作
在这里,我是说我需要能够要求注册管理器对学生加入到数学
101.那将转化成一种叫做操作“addCourse”。
一类的结构是由它的属性来表示。那么,如何才能找到我的属性?通过谈话领域的专家。通过观察我的要求。在我的例子,我知道每门课程都有一个编号,位置,和时间。这转化到三种属性。
类。 (在UML中表示为旁边代表全类金刚石连接相关的类线)。
•依赖€“一个较弱的形式显示客户端并在客户端不具备供应商语义知识供应商之间的关系。依赖关系说:“我需要你的服务,但我不知道你的存在。” (代表在UML作为从客户端向供应商指出的虚线)。
为了找到关系,我再次回到我的序列图。如果两个对象需要“交谈”,必须有一种手段来做到这一点(即,它们的类之间的关系)。
我通常开始时,让一切的关联。当我做更多的分析,我可能会发现我有一个集合,因为我将不得不采取的父子关系照顾。当我进入设计阶段,我发现,因为别人会到该对象传递到我的方法€“,所以我让依赖一个我可能不需要的关联。
图11:关系
在图11中可以看到这些关系。作为协会说,教授可以倾诉的课程设置和课程设置可以跟教授。消息可以发起和数据可以从任何方向流动。聚合是通过在这种情况下,一个场由课程设置的具有向整个â€钻石“表示。这样做的原因聚集会告诉我的开发人员,如果他们摆脱这个课程,他们可能会不得不做一些特殊的课程设置。依赖关系被示为虚线。它说,登记经理取决于调度算法做一些事情。该调度算法要么是该方法的一个参数或由登记管理的方法的一个局部声明。
多重性和导航
多重定义了许多对象如何参与的关系。它是与其它类的一个实例一个类的实例的数量。每个关联和聚集,有两个多重决定使:一个用于关系的两端。多重被表示为编号和*用于表示许多的多重性。
图12:多重性和导航
一个教授的对象是关系到零到四课程设置的对象。一门课程的对象是关系到只有一个教授的对象。我用这个来看看,并确保该处理我的要求。我可以是一个课程设置和由一群教授来队成才?不,因为这表示我只能有一个教授。我能成为一名教授,并在休假?是的,因为这表示我有一个零尽可能的课业负担。我用多重经常帮助我开始捕获和执行我的业务规则。如果你有,例如,说,你必须有至少3名学生不超过10为一疗程一学期要提供一个业务规则,这些多重数字告诉我,我已经纳入了业务规则到这个计划。
导航由箭头示出,并且虽然关联和聚合是双向默认,常常需要限制导航到一个方向。当导航受到限制,加一个箭头以指示导航方向。其中一个我做的事情,在分析和设计阶段是看什么,我想是单向的。通过将箭射向这个图,我说,注册管理器可以将消息发送到课程,因为它知道课程的存在。但课程不知道该注册管理器存在,所以课程不能启动的消息。现在,数据可以在它们之间流动;比如注册管理器可以询问课程,如果它是开放的,过程中可以说是。但是,只有注册管理器可以启动对话。
显然,这里的目标是,你可以的时候,你已经完成了设计,因为它是一个更容易的系统维护继承显示用三角形来获得尽可能多的箭头。由此可见,教授是一个注册的用户,因为是学生。现在,提醒一句。继承是有用的,但是,我们的目标是不使用尽可能多的基业为你的系统将允许。我见过一些非常残酷的制度,因为它们继承了17级深。如果他们改变了一件事,它成为一场灾难。所以经验法则是使用继承,只有当你真正做到有继承的情况。
状态转换图
状态转换图显示了一个给定类的生活史。它表明,导致过渡从一个状态到另一个的事件,以及从一个状态改变导致的行动。
图14:状态转换图
我使用状态转换图用于通常有大量的动态行为对象类。按钮是一个€|此按键关闭;我不会做一个状态图吧。但是,有很多的动态行为的对象类,我可能不得不考虑的对象的状态。
我通过显示的状态下,这是一个圆形的三角形启动。我可以有启动状态,我可以有停止的状态,并显示为公牛的眼睛。我也可以有一定的状态,或保护过渡(东西只有当条件是真实的发生),或东西的时候,我州内所发生的转变。我看这个图,看一门课程的状态转换图。它开始在初始化状态,我留在了状态,直到我得到一个“添加学生”的消息。当我得到的消息,我把我的学生的数量为零,我过渡到开放状态。你会在图14中,我有一个入口看到,为什么它的存在的原因是,我进入那个状态的两种方式。它说,无论你怎么来进入状态,我想您注册学生。当我离开该国,伯爵的变化来跟踪学生在课程的数量。我可以不断增加的学生,直到我到10,然后我去关闭状态。一旦课程完成,我转换到停止状态。无论我在哪里,然后,如果我取消事件的过渡,我通知我的学生,然后过渡到停止状态。
对于有大量的动态行为的对象类,这是非常值得做的一个状态图,以获得有发生一切的句柄。问问自己,当我得到一个消息,会发生什么?当我得到的消息,该怎么办?都送什么消息给我?很多这些消息的成为对象类别的动作,如在本实施例中,其中添加一个学生的操作。很多这些动作,如设置数,增加计,检查次数,这些都成为特定对象类的私有操作和状态图是我看得出来。
你怎么知道,如果你有一个动态的对象类?再次,回到序列图。如果你有一个对象类是上了不少的序列图和它的获取和发送大量的邮件,这是一个很好的迹象这是一个相当活跃的对象类,它可能应该有一个状态图吧。也用于聚合,在那里你拥有整个的部分,我做的每一个全总的状态图。我这样做主要是因为整个总量往往是管理的消息,这使得它的动态负责。
组件图
当然没有系统能够在不考虑物理世界来构建。这就是组件图进来。它们被用来说明软件组件之间的组织和依赖,包括源代码组件,运行时间组件,或可执行组件。组件是示出作为与上侧的两个较小的矩形的大型矩形,如图15所示。
图15:组件
这些轮的事情表示接口(通常称为棒棒糖表示)。在这种情况下,他们表明Register.exe取决于接口两者Course.dll和People.dll。这意味着,如果这些接口的改变,它会影响Register.exe。我知道,有这么说,这条规则,当你建立接口“你不改变接口”。但是,没有任何人的实际工作,其中该规则被执行?这个图告诉我们是使用了哪些可执行对我的处理器运行的接口。
图16:部署图
扩展UML
我想强调的关于UML的最后一件事是,它可以延长。当他们建造了UML,他们很明智地意识到,有没有办法,他们可以创建一个能取悦所有的人所有的时间的符号。于是,他们给了我们一个刻板的概念。刻板印象说,我可以采取基本的建模元素,并赋予它更多的意义。定型可用于分类和延伸协会,继承关系,类和组件。
图17:网络刻板印象的例子
图17显示了我们的Web定型的图。一个网页通常具有客户端上运行的服务器之类的东西上运行的东西。如果你正在构建基于Web的应用程序,什么是运行在客户端和服务器是至关重要的。因此,我们有一整套的陈腐观念表明。小轮表示在服务器上运行的东西。因此,只要看看这个图,我可以看到在服务器上运行,哪些客户端上运行,并且他们必须处理一下业务对象。

“——————————————————————————————————————————————————

支持翻譯:http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“該UML是指定,可視化,構造和文檔軟件系統的所有工件的標準語言。”
活動圖
開始通過一些UML圖走的邏輯位置是看活動圖。
圖2:活動圖
活動圖顯示控制流。如圖2中所示,可以看到表示為圓角矩形活動。活動通常動作狀態€“指出自動過渡到下一個狀態的動作完成之後。該填充圓表示活動圖的開始€“,其中控制開始流動。用箭頭表示視線告訴你如何擺脫因活動。同步欄顯示活動並行是如何發生的。我可以防守,說一個過渡“我要你去僅當此條件為真這個活動,”我可以告訴你在哪裡停止。現在,如果你是一個一定的年齡,你可能會看到這個活動圖,並認為,“嗯â€|看起來像一個流程圖”。而這正是它是什麼,但我不這樣做下來的編程水平。通常情況下,我很早就上使用我的分析和設計過程的活動圖顯示業務流程。我也將用它們來顯示每個我的用例可能是一個活動來說明用例有發生。我還用活動圖顯示的東西我用例之間如何流動。
但關於UML的偉大的事情之一是它的多功能性。所以,當我在生命週期的初期使用活動圖,其他人完全可以在不同的階段使用它們。我見過的人使用的活動在設計水平,他們有一個非常複雜的算法集為特定的類圖了。而很多人用它來顯示一個類的方法之間的流動。
系統。演員表示為堅持數字。
圖4:演員
我的工作彌補了這一介紹UML的例子是一個課程註冊系統的小模型。因此,在這種情況下,第一件事我就開始我的分析過程是問,什麼時候“誰去與該系統進行交互?”
對於課程註冊模式,我有一個登記處,一位教授和學生。我也有一個外部計費系統。該計費系統也有資格作為一個演員。 (參見,演員不必是一個人€“是任何與系統交互,但是該系統的外面。)
用例是由演員在系統中的對話進行關聯交易的序列。或者,把它的英文,一個用例是功能性的塊。而這裡的關鍵:它不是一個軟件模塊A€“這是東西,提供價值的演員。
用例顯示為橢圓形,並找到他們最簡單的方法是看每個演員,問自己為什麼他們要使用的系統。就我而言,我的註冊商是要保持的課程,我的教授會要求名冊,我的學生保持時間表,和我的計費系統收到計費信息。所以,我從客戶的角度看它,並要求,創建我的用例“,所以,老總系統參與者,你為什麼要使用這個系統?什麼樣的價值為什麼這個系統提供給你?”
下一步,一旦你已經確定你是如何將演員與系統進行交互,是做記錄您的用例。每個用例需要與事件流進行記錄,這是從看演員的點完成。它應詳細說一下系統必須執行用例時,提供給演員。通常情況下,它會顯示之類的東西用例是如何開始和結束。這是否用例有什麼事情要做?你必須在正常事件的流程(我稱之為“幸福的日子”的情況),這裡的一切工作。然後你會得到事件的異常流量,在“未雨綢繆”的情景。當系統無法正常工作,會發生什麼?我已經通過我的記錄,我總是與快樂的日子方案開始的事件流中。
採取作為一個例子,走到自動取款機。您步行到ATM和插入你的卡。它要求你的PIN碼。你走進它,並詢問您想做些什麼。你說“我想要一些錢。”它要求這些錢應該服用。你告訴它把它從你的支票賬戶。它要求有多大。你說的$ 100,00。然後,奇蹟發生了â€|它給你$ 100,00。然後,它會詢問您是否另一個事務。你說沒有。它給你的卡的背面,給你一張收據,交易結束。這就是快樂的日子場景。
第二個場景。你去到ATM,插入卡,並輸入PIN碼。在ATM告訴您這是錯誤的PIN。您再次輸入您的電話號碼。同樣,你被告知的密碼不正確。你在我的課程註冊的例子,比如,你可以看到,有很多的“如果X,則Y”的工作流程。這就是你希望你的客戶來幫助你。獲取協議早期意味著你的客戶了解這些方案並說:“是的,這就是我們想要的。”用例是要確保你正在構建真的是客戶需要什麼的好方法,因為它們顯示的演員,用例,以及它們之間的關係。
圖5:用例圖
因此,我們有一個偉大的圖,它以圖形方式顯示我什麼?答案很簡單€“這是一個偉大的圖,它顯示了系統的一個很好的概述。它顯示的是在系統(演員),並且系統必須提供(使用例)的功能之外。如果你需要考慮到一個遺留系統,這裡就是你對付它。迫使我與這些類型的接口工作在項目很早意味著我不會面臨著等到開始編碼的前景弄清楚如何我要談給黑盒子,我不能改變。
你應該知道的使用案例一件事是用例的實現。這是“如何”的使用情況。它通常包含三種不同類型的圖一鬥:序列圖,協作圖,而我們所說的參與類的視圖類圖。用例實現基本都組合在一起了許多與用例設計文物的一種方式。
序列圖
序列圖顯示安排在一個時間序列對象交互。我可以使用的事件流,以確定哪些對象和交互我將需要完成由事件流中指定的功能。
圖6:序列圖
圖6示出了如何一個學生成功被添加到一個療程。學生(讓我們稱他為喬)填寫一些信息並提交表單。該表格隨後會談到經理,並說“添加喬數學101”經理告訴數學101,它具有增加的學生。數學101說,第1節“你開?”在這種情況下,第1條回复,他們是開放的,所以數學101告訴節1添加這個學生。同樣,序列圖是偉大的工具,在開始的時候,因為他們表現出你和你的客戶一步一步有什麼發生。
從一個角度分析來看,我發現這些年來序列圖是在幫助我推動的需求非常強大的;特別是要求,是很難找到的。用戶界面的要求,比如,是臭名昭著,因為你總是能得到只是不可測試的要求。像這樣的常見的UI要求是“這個系統應是用戶友好的。”你們有多少人見過一個友好的電腦嗎?其中的一個類型的圖的好處是,從代表一個人的演員來的每一行,告訴你的東西在你的UI必須提供由該人所需要的能力。換句話說,你可以使用序列圖來驅除測試的用戶界面需求。
序列圖,因此,很好的顯示是怎麼回事,驅動了需求,並與客戶合作。這通常會導致問題,但是,做多少你需要創建?我的回答是,“直到你做的不夠。”你會發現當你做,你達到一個地步,你不會找到任何新的對象,沒有找到任何新信息序列圖,並且,你一遍又一遍地輸入同樣的事情。在喬加盟數學101的例子中,我們了解到,這個過程將是相同的,如果喬想加入歷史101.因此,經驗法則,對於每個用例的每一個基本流程做一個序列圖。做為高級別,有風險的情況下的序列圖,而應該是足夠的。這就是我多少序列圖做到。
要記住,是一個協作圖是場景的只是不同的看法,你可以來回走順序圖和協作圖之間獲得最能闡明你的觀點的看法。
有時,你可能會聽到“交互圖”。有時人們將統稱協作圖和交互圖的序列圖。
類圖
一類是具有共同結構,共同行為,共同關係和共同語義對象的集合。你通過檢查序列和協作圖中的對象找到它們,並且它們在UML作為具有三個隔室的矩形表示。
圖8:類
第一個參數說明類名,第二個顯示出其結構(屬性),而第三個顯示其行為(操作)。這些車廂可以抑制然而,這樣您就可以看到剛才的名字,只是名稱和屬性,或全部三個。有一件事你還應該知道的是,這一點很重要,命名類時,使用領域的詞彙和挑選的標準。對於這種情況下,我的課都是以大寫字母開頭的單數名詞。您可以選擇以不同的方式做到這一點,那沒關係。什麼事做的是,你選擇一個標準,並堅持下去,使一切是整個項目一致的項目之前。
類圖顯示您的系統的靜態特性。這些圖顯示的類及其中的系統的邏輯視圖的關係的存在。你將有一個模型中的許多類圖。
在類圖中找到的UML建模元素包括:
類和它們的結構和行為。
協會,聚集,依賴和繼承關係。
多重性和導航指示
角色名稱。
看看圖9.此圖顯示了操作(行為):在該類的對象可以做什麼。我通過看我的交互圖找到我的操作。
圖9:操作
在這裡,我是說我需要能夠要求註冊管理器對學生加入到數學
101.那將轉化成一種叫做操作“addCourse”。
一類的結構是由它的屬性來表示。那麼,如何才能找到我的屬性?通過談話領域的專家。通過觀察我的要求。在我的例子,我知道每門課程都有一個編號,位置,和時間。這轉化到三種屬性。
類。 (在UML中表示為旁邊代表全類金剛石連接相關的類線)。
•依賴€“一個較弱的形式顯示客戶端並在客戶端不具備供應商語義知識供應商之間的關係。依賴關係說:“我需要你的服務,但我不知道你的存在。” (代表在UML作為從客戶端向供應商指出的虛線)。
為了找到關係,我再次回到我的序列圖。如果兩個對象需要“交談”,必須有一種手段來做到這一點(即,它們的類之間的關係)。
我通常開始時,讓一切的關聯。當我做更多的分析,我可能會發現我有一個集合,因為我將不得不採取的父子關係照顧。當我進入設計階段,我發現,因為別人會到該對象傳遞到我的方法€“,所以我讓依賴一個我可能不需要的關聯。
圖11:關係
在圖11中可以看到這些關係。作為協會說,教授可以傾訴的課程設置和課程設置可以跟教授。消息可以發起和數據可以從任何方向流動。聚合是通過在這種情況下,一個場由課程設置的具有向整個â€鑽石“表示。這樣做的原因聚集會告訴我的開發人員,如果他們擺脫這個課程,他們可能會不得不做一些特殊的課程設置。依賴關係被示為虛線。它說,登記經理取決於調度算法做一些事情。該調度算法要么是該方法的一個參數或由登記管理的方法的一個局部聲明。
多重性和導航
多重定義了許多對象如何參與的關係。它是與其它類的一個實例一個類的實例的數量。每個關聯和聚集,有兩個多重決定使:一個用於關係的兩端。多重被表示為編號和*用於表示許多的多重性。
圖12:多重性和導航
一個教授的對象是關係到零到四課程設置的對象。一門課程的對象是關係到只有一個教授的對象。我用這個來看看,並確保該處理我的要求。我可以是一個課程設置和由一群教授來隊成才?不,因為這表示我只能有一個教授。我能成為一名教授,並在休假?是的,因為這表示我有一個零盡可能的課業負擔。我用多重經常幫助我開始捕獲和執行我的業務規則。如果你有,例如,說,你必須有至少3名學生不超過10為一療程一學期要提供一個業務規則,這些多重數字告訴我,我已經納入了業務規則到這個計劃。
導航由箭頭示出,並且雖然關聯和聚合是雙向默認,常常需要限制導航到一個方向。當導航受到限制,加一個箭頭以指示導航方向。其中一個我做的事情,在分析和設計階段是看什麼,我想是單向的。通過將箭射向這個圖,我說,註冊管理器可以將消息發送到課程,因為它知道課程的存在。但課程不知道該註冊管理器存在,所以課程不能啟動的消息。現在,數據可以在它們之間流動;比如註冊管理器可以詢問課程,如果它是開放的,過程中可以說是。但是,只有註冊管理器可以啟動對話。
顯然,這裡的目標是,你可以的時候,你已經完成了設計,因為它是一個更容易的系統維護繼承顯示用三角形來獲得盡可能多的箭頭。由此可見,教授是一個註冊的用戶,因為是學生。現在,提醒一句。繼承是有用的,但是,我們的目標是不使用盡可能多的基業為你的系統將允許。我見過一些非常殘酷的制度,因為它們繼承了17級深。如果他們改變了一件事,它成為一場災難。所以經驗法則是使用繼承,只有當你真正做到有繼承的情況。
狀態轉換圖
狀態轉換圖顯示了一個給定類的生活史。它表明,導致過渡從一個狀態到另一個的事件,以及從一個狀態改變導致的行動。
圖14:狀態轉換圖
我使用狀態轉換圖用於通常有大量的動態行為對象類。按鈕是一個€|此按鍵關閉;我不會做一個狀態圖吧。但是,有很多的動態行為的對象類,我可能不得不考慮的對象的狀態。
我通過顯示的狀態下,這是一個圓形的三角形啟動。我可以有啟動狀態,我可以有停止的狀態,並顯示為公牛的眼睛。我也可以有一定的狀態,或保護過渡(東西只有當條件是真實的發生),或東西的時候,我州內所發生的轉變。我看這個圖,看一門課程的狀態轉換圖。它開始在初始化狀態,我留在了狀態,直到我得到一個“添加學生”的消息。當我得到的消息,我把我的學生的數量為零,我過渡到開放狀態。你會在圖14中,我有一個入口看到,為什麼它的存在的原因是,我進入那個狀態的兩種方式。它說,無論你怎麼來進入狀態,我想您註冊學生。當我離開該國,伯爵的變化來跟踪學生在課程的數量。我可以不斷增加的學生,直到我到10,然後我去關閉狀態。一旦課程完成,我轉換到停止狀態。無論我在哪裡,然後,如果我取消事件的過渡,我通知我的學生,然後過渡到停止狀態。
對於有大量的動態行為的對象類,這是非常值得做的一個狀態圖,以獲得有發生一切的句柄。問問自己,當我得到一個消息,會發生什麼?當我得到的消息,該怎麼辦?都送什麼消息給我?很多這些消息的成為對象類別的動作,如在本實施例中,其中添加一個學生的操作。很多這些動作,如設置數,增加計,檢查次數,這些都成為特定對象類的私有操作和狀態圖是我看得出來。
你怎麼知道,如果你有一個動態的對象類?再次,回到序列圖。如果你有一個對象類是上了不少的序列圖和它的獲取和發送大量的郵件,這是一個很好的跡象這是一個相當活躍的對象類,它可能應該有一個狀態圖吧。也用於聚合,在那裡你擁有整個的部分,我做的每一個全總的狀態圖。我這樣做主要是因為整個總量往往是管理的消息,這使得它的動態負責。
組件圖
當然沒有系統能夠在不考慮物理世界來構建。這就是組件圖進來。它們被用來說明軟件組件之間的組織和依賴,包括源代碼組件,運行時間組件,或可執行組件。組件是示出作為與上側的兩個較小的矩形的大型矩形,如圖15所示。
圖15:組件
這些輪的事情表示接口(通常稱為棒棒糖表示)。在這種情況下,他們表明Register.exe取決於接口兩者Course.dll和People.dll。這意味著,如果這些接口的改變,它會影響Register.exe。我知道,有這麼說,這條規則,當你建立接口“你不改變接口”。但是,沒有任何人的實際工作,其中該規則被執行?這個圖告訴我們是使用了哪些可執行對我的處理器運行的接口。
圖16:部署圖
擴展UML
我想強調的關於UML的最後一件事是,它可以延長。當他們建造了UML,他們很明智地意識到,有沒有辦法,他們可以創建一個能取悅所有的人所有的時間的符號。於是,他們給了我們一個刻板的概念。刻板印象說,我可以採取基本的建模元素,並賦予它更多的意義。定型可用於分類和延伸協會,繼承關係,類和組件。
圖17:網絡刻板印象的例子
圖17顯示了我們的Web定型的圖。一個網頁通常具有客戶端上運行的服務器之類的東西上運行的東西。如果你正在構建基於Web的應用程序,什麼是運行在客戶端和服務器是至關重要的。因此,我們有一整套的陳腐觀念表明。小輪表示在服務器上運行的東西。因此,只要看看這個圖,我可以看到在服務器上運行,哪些客戶端上運行,並且他們必須處理一下業務對象。

“——————————————————————————————————————————————————

Traduction: Support: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”U UML è la lingua lingua standard di un quaternu, visualizing, custruisce, è documenting tutti i archiulogica di un sistema di software lìbbiru.””
attivitati Diagrams
U locu u penseru logicu à fà la partendu marchja à traversu certi di i diagrams UML hè par fighjulendu diagrams attività.
Figura 2: m’agiterai Attività
diagrams attività mostranu l ‘apporti di cuntrollu. As illustrati in Figure 2, pudete vede attività rapprisintatu caraìbe catturati. Activités sunnu tipicamenti stati azzioni â € “”ni cunta ca passaggiu in autumàticu à u Statu dopu, dopu à l ‘azzioni è cumpleta. Li pieni in cìrculu rapprisenta l ‘inizziu di l’ m’agiterai attività â € “”unni lu flussu di alfabbèticu cuntrollu. Transitions indicatu comu frecci addumati vede cumu si movi da l ‘attività à l’ attività. aste Synchronization vede cumu attivitati succede à corri. I pò surviglià un passaggiu chi dici: “”Vogliu voi à andà à sta filiera sulu siddu sta cundizione hè vera,”” e ju vi pò fà vede induv’ellu si ferma. Avà sè vo Patrunu Du una certa età, ti Mulateri Di L’ùrtima look at Puiseux diagram attività è pensanu chì, “”Hmm â € | chi si prisenta comu un flow chart.”” È chì hè esattamente ciò ch’ella hè, francu aghju micca staiu facennu falà à u livellu di prugrammazione. Na cosa tìpica, I aduprà un m’agiterai attività abbastanza prestu, in u mio prucessu anàlisi e cuncipitura è a mostra workflow affare. I Mulateri Di L’ancu elli usu pi mustrari unni ognunu di i mio casi usu Pò esse in un ‘attività à illustrate ciò chì accade usu havi a succediri. I puru aduprà diagrams attività à vede quantu a purtata di e cose trà u mio casi usu.
Ma unu di li granni di cosi c’avieunu a UML è u so sta. So cum’e aduprà diagrams attività à u principiu di u Luca, l ‘altri ponu bolit in una fase sfarente sanu. Hò vistu partì i populi aduprà attività diagrams falà à u livellu disignu unni avìanu nu nsemi assai cumplessa di alguritmi pi na particulari di classi. È tanti genti bolit a mostranu l ‘apporti trà i metudi di na classi.
u sistema. Attura sunnu rapprisintati arresta comu e figure bastone.
Figura 4: attori
L ‘esempiu chì aghju travagliatu, su per sta ntruduzzioni a lu UML hè un pocu mudellu di un sistema di iscrizzione corsu. So a stu puntu, la prima cosa chi putissi fari, quannu, accuminciannu me prucessu analisi hè da dumandà à, “”chì si puderà interagisce cu stu sistema?””
Di u mudellu di iscrizzione corsu, ju nun haiu un registrar, un prufissuri, è un studiente. I hannu puru nu sistema Bilingue esternu. Stu sistema Bilingue qualifies macari comu nu nomu. (Guarda, nu nomu nun havi a èssiri na pirsuna â € “”hè qualcosa chì jòni ri lu sistema ma hè fora di u sistema.)
Un casu di usu hè un ordine di compra ligata joué par un attore in u sistema di a un dialogue. Or, à mettela in inglese, un casu di usu hè un Chunks di a funziunalità. È quì, d’u tastu: ùn hè più una Modulo â prugrammu € “”hè calcosa chì accerta a valurizazioni di u attore.
Usu casi sò mustrati cum’è ovals, è u modu più faciule à truvà elli è à circà a ognu di u vostru attori è dumandà présenter poita vonnu pi usari lu sistema. In u mio casu, ma registrar si passa à u rispettu di a curriculum, u mo prufessore si puderà dumandà un Sinonimi, u mio studiente ùn esci da u travagghiu, è u mio sistema Bilingue riceve i infurmazioni Bilingue. So I creà u mio casi usu pi fighjulendu lu da u puntu di vista lingua è dumandendu, “”Innò, sistema aiat dadu attore, ché vo vulete aduprà u sistema? Chì valore ùn stu sistema derà à voi?””
U passu prossimu, quand’è vo a francisata troppu idintificatu cumu u vostru atturi sarà scambia cù u sistema, è Fate dato i vostri casi usu. Ogni casu usu vole à esse studiata cù l ‘apporti di l’ abbinimenti, e chistu veni fattu da u puntu di vista di l’attore. Avissi a tecnica chì u sistema tocca à purtà à u famosu quandu hè eseguitu u casu usu. Na cosa tìpica di lu Vi mustraraghju à e cose cum’è comu lu casu di usu cumencia, è finisce. Chì e cose ùn stu casu usu avemu a fari? You Mulateri Di L’hannu lu nurmali, a purtata di l ‘abbinimenti (ciò chì mi chiamu la banna “”ghjorni felici””), induve tuttu travaglia. Allora vi Mulateri Di L’acquistu di u flussu carenza di abbinimenti, la banna “”Bande à part””. Nzo chi succèri quannu lu sistema ùn viaghja? Corsu a francisata troppu trovu da documenting mio purtata di l ‘abbinimenti ca iu sempri eruditi nizzianu cu li filici situazione di ghjorni.
Pagliacci, comu nu isempiu, marchjendu finu a nu café. You à marchjà davanti à u sofa e inserisci a vostra carta. Hè dumanna di u vostru nùmeru PIN. You entre in lu, è vi sò dumandatu ciò chì vo vulite fà. You diri “”Vogghiu qualchi soldi.”” Si dumanda: induve i soldi deve esse pigliata da. Ti dicu à piglialu: ecculu ddà da u vostru contu à cuntrollà. Si dumanda: how much. Dite $ 100,00. Allora a magia succèri â € | è chì vi dà $ 100,00. Allora si rivolgi a s’è vo vulete un altru transazzione. You dì nudda. Hè chì vi dà u vostru annonce spaddi, ti duna na avè ricivutu, è u transazzione hè sopra. Hè a situazione cuntenti ghjornu.
Seconda situazione. You à ricullà à i sofa, inserisci a vostra carta, è entre in u vostru PIN. U sofa tù dici ch’ellu si trattava d’u PIN sbagghiatu. You entre dinò u vostru numaru. Avvene ti diciunu ca lu PIN è sgarratu. You In u mio corsu esempiu iscrizzione, per esempiu, si pò vidiri ca ci sunnu assai di “”siddu X poi Y”” workflows. Hè duve vo vulete i vostri clienti à aiutà ti fori. Messa accordu significa principiu di u vostru clienti Cunteni sti casi e dici: “”iè, hè ciò ch’è no vulemu.”” Usu casi sunnu un granni modu d’assicurà chì ciò chì vo sunari costruzzioni hè veru ciò chì i clienti voli, picchì si mostranu l ‘attori, i casi usu, e la rilazione trà elli.
Figura 5: Aduprà m’agiterai casu
So avemu un gran m’agiterai chì à mè ciò chì mostra graphically? A risposta hè simplice â € “”ghjè un gran m’agiterai chì mostra un bonu riassuntu di u sistema. Ci insegna ciò chì hè fora di u sistema (atturi) e la funziunalitati, chì u sistema ci vole à purtà (casi usu). S’elli ci hè un sistema di pensà, ci vole à piglià in parte, quì, d’unni si usa cun ella. à mè è sò custretti à travaglià incù sti tipi di interfaccia assai prestu in u prugettu signìfica ca ju nun sarà cunfruntatu cù u filu di aspittà à linguistic accumincia a cumprènniri comu li aghju decisu chè vocu à publicà a ddu fait neru chì ùn pò cambià .
Unu di più cosa vo ùn sapete su casi usu hè l’usu casu di realisazione. Chistu è lu “”come”” di l ‘usu casu. Hè di sòlitu un friscalettu E chì cuntene tri diffirenti tipi di diagrams: diagrams siquenza, diagrams cullaburazioni, è un m’agiterai classi chè no chjama una vista di i classi participari. Usu casu realizations veni cunziddiratu nu modu di gruppu inseme un nùmeru di rimarchevuli chì si raportanu à u generu d ‘un casu usu.
Diagrams siquenza
diagrams siquenza mostranu onore oggettu almanaccatu in una siquenza tempu. I pudete puru aduprà u cursu di l’evenimenti di definisce ciò chì sò prupitati e onore Vi tocca à rializà u funziunalitati pricisatu da lu cursu di l’abbinimenti.
Figura 6: m’agiterai Sequence
Figura 6 mostra come un studiente di piglià si aghjuntu à un corsu. U studiente (chì d’u ciamarru Joe) lustru di a arcuni nfurmazzioni e suttumette u furmulariu. A forma seriu, dopu à u capu è dice: “”aghjunghje Joe à Math 101.”” Lu capu di nzigna Math 101 ca lu nomu havi a jùnciri un studiente. Math 101 dici a Section 1 “”si voi chjamate?”” In stu casu, Section 1 risposte chì si sò aperta, accussì Math 101 dici a sizzioni: 1 d ‘aghjunghje stu studiente. Mugliera, diagrams ordine sò granni arnesi in u principiu, pirchi tu e tò clienti mostra un passu-di-passu chi avi a succediri.
Da un puntu di vista analisi, Corsu a francisata troppu truvò nantu à l ‘anni ca diagrams ordine sò assai putenti in cuntribuiscia à mè voiture esigenze; soprattuttu esigenze chì sò difficiuli à truvà. esigenze interfaccia Qype, per esempiu, sò noti picchì ti pari ca sempri pi pigghiarisi esigenze, ca nun sunnu sulu testable. A esigenza di Ui cumuni like this è “”stu sistema sarà user-simpatica.”” Quanti vo avete scontra à un urdinatore è simpaticu? Unu di i benefici di sti tipi di diagrams hè chì ogni linia chì venenu da Andronicus è nu nomu ca rapprisenta na pirsuna, si dici ca calcosa in u vostru Ui hà a scegli un CAPABILITY abbisugnava pi dda pirsuna. Nta àutri paroli, pudete puru aduprà diagrams siquenza a scaccià esigenze interfaccia me testable.
diagrams ordine sò, dunque, bona per mustrà chi succede, di scacciò i vostri bisogni, è di travaglià incù i clienti. Ca di solitu chì sbocca nantu à a quistione di, sippuru, di quantu cosi nun vi tuccherà à creà? I mo risposta hè, «sinu à a pudete fà abbastanza.”” You sona u va a truvari fora quandu vo fate diagrams ordine chì tù ghjunghje sin’à un puntu duve ùn si sona u truvannu un specchiu novu uggetti, nun truvannu un specchiu novu missaghji, è chì vo sunari beaten a listessa cosa pi ogni vìarsu. Nta l ‘esempiu di Joe partendu da Math 101, avemu amparà chì u prucessu si fussi lu stissu si Joe vulia à veda Storia 101. So, signuria di pollice, faire un m’agiterai ordine per ogni purtata di basi di ogni casu usu. Faire un m’agiterai siquenza di-altu livellu, casi risicatu, e chi avissi a èssiri abbastanza. Hè quantu diagrams siquenza I fari.
si ricorda di quì, hè chì un m’agiterai cullaburazione hè ghjustu: una vista sfarente di na banna e si pò turnari e, tra diagrams siquenza e diagrams cullaburazione pè ottene a cunsidarazioni chì megliu è u vostru puntu.
Di tantu in tantu, ci pudia sente a frasa “”diagrams azioni.”” Quarchi vota populu avarà nzèmmula a na m’agiterai cullaburazione è un m’agiterai siquenza comu nu m’agiterai azioni.
Scola Diagrams
A formula è na cullizzioni di li suggetti cun struttura cumunu, cumpurtamentu cumunu, raporti cumuni, e lingue cumune. You truverà par tocca à l ‘uggetti di a siquenza e cullaburazioni diagrams, è ch’elli sò raprisintati à u UML comu un rectángulo cù trè compartments.
Figura 8: Classes
Lu primu compartment ammustra lu nomu di classi, a seconda mostra a so struttura (spicificu), e lu terzu, mostra, u so cumpurtamentu (funziunamentu). Sti compartments pò ssiri suppressi, pirò, accussì ca si pò vede cum’è u nomu, sulu lu nomu e la spicificu, o di tutti tri. Una cosa vi duvite dinò cunnosce è chì hè impurtante, quandu naming bassa, pi usari lu vucabbulariu di lu duminiu di e accogghiri ‘na lingua standard. Pi chistu, p’asempiu, la me scuntentu sò tutti paroli singulari ca accumincianu cu na littra capitali. Pudete sceglie à fà lu in un’antra manera, è chì ùn conta. Chi mi ‘nteressa a materia è chì nanzu u vostru prughjettu si coglie un mudellu è bastone, cu lu stringiu tantu ca’ ccu tuttu ca la fiducia à traversu u prugettu.
Scola Diagrams vi danu a natura fermu di u vostru sistema. Sti diagrams mostranu l ‘esistenza di i classi è i so raporti à la vista, u penseru logicu di un sistema. You averemu assai diagrams di classi in un mudellu.
U elementi UML artificiali trovu in diagrams classi incrudunu:
Cucina è a so struttura è e cumpurtamentu.
raporta Association, FataTurchina, dependency, è una làscita.
indicatori multiplicità è navigazioni
de famille rolu.
Pigliate un vistighe Figure 9. Stu m’agiterai mostra u funziunamentu (cumpurtamentu): ciò chì un oggettu in chì classi po ‘fari. Aghju trovu u mio opérations par fighjulendu u mio diagrams interazzioni.
Figura 9: Docenti
Quì mi sentu dicendu chì t’aghju bisognu à esse in gradu di dumandà à u capu di tassa à aghjunghje un studiente di a Math
101. Ddu d’esse pràticu traduce in una cuuperazione chiamatu “”addCourse.””
A struttura di na classi hè figurata da u so utilisazione. So cumu ùn aghju trovu u mio spicificu? Par parla a sperti duminiu. Par fighjulendu u mio bisogni. In u me esempiu, I amparà chì ogni offerta corsu hà un numeru, un locu, è un certu tempu. Stu traducennu fora à trè spicificu.
scuntentu. (Rapprisintatu in u UML comu na linia di culligamentu di i classi culligata cu nu diamanti fiancu à i classi ca rapprisenta lu tuttu.)
â € ¢ Dependency â € “”una forma scintìfica ca mostranu lu rapportu tra un cliente è un Sec.XV induve u cliente ùn hà cunniscenza simàntici dâ Sec.XV. A dependency dici: “”aghju bisognu di u vostru servizii, ma ju nun sacciu chi tu esisti.”” (Rapprisintatu in u UML comu na linia quaderni mustrannu da u cliente à u Sec.XV.)
Da truvà e rilazione, ancora na vota, Vaiu e tornu à u mio m’agiterai siquenza. Sè dui oggetti bisognu di “”parrari””, ci avi a essiri na cosa pi fari accussì (i.e., na rilazzioni tra li classi).
I tipicamenti partendu fora è fà tuttu u so associu. Comu mi sentu fà più analisi, mi putissi truvari ju nun haiu un FataTurchina perchè aghju decisu chè vocu à avè a causa di na rilazzioni Parent-zitellu. Quannu trasu nta la fasa design, I p’attruvari ca mi putissi micca bisognu di un associu chì essiri ‘n’àutru si puderà passà per oggettu in unu di i mio metudu â € “”accussì mi fazzu lu in un dependency.
Figure 11: scrittura
In Figura 11 vidite sti rilazzioni. As associu, dici lu Prufissuri pò parrari a lu Partita di u corsu, è u Partita di u corsu pò parlà à u prufissori. Missaghji pò pàrtiri e données pò purtata da ogni direzzione. Aggregation hè spartu da avè u Diamant versu u mondu â € “”in stu casu, un corsu hè cumpostu di pristazioni di u corsu. Lu mutivu di stu FataTurchina saria a dicu a me sviluppori ca si cci guariri di ‘stu corsu, si Mulateri Di L’ùrtima hannu a fari quarchi cosa particulari cu l’ pristazioni di u corsu. Dependencies sò mustrati cum’è una ligna quaderni. Hè cusì chì u capu di iscrizzione dipenda da nantu à l ‘algutitimu Calendario à fà calcosa. U algutitimu Calendario si manifisteghja sighi un paràmetru à unu di i metudi, o sighi dichjarata a misura di a manu di unu di i results for di lu diritturi Scrizzione.
Multiplicità e di navigazzioni
Multiplicità definisci comu tanti uggetti di participà à un rapportu. Hè u numaru di casi di unu di classi riguardanti unu esempiu di l ‘àutri pupulani. Per ogni associu e FataTurchina, ci sò duie e decisioni multiplicità di fà: una per ogni fine di u rapportu. Multiplicità veni rapprisintatu comu nu nùmmuru e na * Nfatti veni usatu pi rapprisintari na multiplicità di tanti.
Figure 12: multiplicità è navigazioni
One ogetti Prufissuri ca è sumigghianti a zeru-a-quattru Partita di u corsu Objects. Unu di u corsu chì porghjenu ogetti è sumigghianti a pròpiu unu ogetti Prufissuri. I aduprà sta a taliarlu e ricunnoscia chì stu dà capu à u mio bisogni. Can I esse un Partita di u corsu è esse squadra di-insignati da una calata di li prufissura? No, picchì chistu dici: I puderete gode di unu sulu di prufissuri. Can I essa un prufissori, è, sia nantu, sabbatical? Iè, perchè stu dici ju nun haiu un zeru pussibule, carricu sicuru. I aduprà multiplicità à spessu à aiutà à mè cumincianu a clientella, è rispettendu e règule di u mio impresa. Sè vo avete, per esempiu, una regula los chi dici, si deve avè à u minimu 3 studienti è senza più cà 10 di un corsu per esse uffertu in un ultimu, sti nummari multiplicità di dirimi Corsu a francisata troppu ncurpurata ca règula los nta stu pruggettu.
Navigation hè spartu da una freccia, è ancu s’è associ è aggregations sò Bi-directionnel par genericu, hè spessu preziosi pè limità a navigazioni à una direzzione. Quandu a navigazioni hè limitata, hè aghjustatu un arrowhead à insignà a direzzione navigational. Unu di li cosi fazzu duranti li fasi anàlisi e cuncezzione hè look at ciò ch’e vogliu esse suffissu-directionnel. Par misiru ‘i mura nta stu m’agiterai, ti dicu ca lu diretturi Scrizzione, pudete mandà un messagiu à u corsu, perchè ùn sà esisti u corsu. Ma u corsu ha nudda idia ca esisti lu diritturi Scrizzione, e cuscì u corsu ùn pò avvià un messagiu. Avà dati pò tràsiri tra d ‘iddi; per esempiu, lu diretturi Scrizzione pò dumandà à u corsu s’ellu hè aperta è u corsu pò diri ca si tratta. Ma sulu quannu lu diritturi Scrizzione puru principià chi cunversazione.
Currispundenu u scopu quì hè pè ottene comu tanti frecci addumati comu vi ponu da u tempu vi a francisata troppu hè finitu i dicori, picchì si tratta d’un sistema tantu fàciule à rispettà a patrimoniu hè spartu cù un triangulu. Sta mostra chì u prufissori è na Qype Scrizzione, comu hè u Student. Ora, cu ‘na parola di stu cunsigliu. Lascita hè interessante, pirò, lu scopu hè micca a usari comu tantu una làscita cum’è u vostru sistema ferà. M’anu vistu parechji sistemi veru aspettu brutali unni avìanu làscita 17-livelli prufonda. S’elli canciata na cosa, sendu un scumpientu. So i reguli di punta è à aduprà una làscita sulu quandu vi ferà quessa ùn avè un pensamentu in lascita.
Diagrams Curie Statu
A transition diagram Statu, mostra, a storia a vita di nu datu di classi. Hè ammustra lu evenimenti chì causari nu passaggiu da unu Statu à l ‘altru, è l’ azzioni ca un bilanciu da un cambiamentu Statu.
Figure 14: transition diagram Statu
I aduprà diagrams transizzioni statu di i classi oggettu chi cerchi hannu assai di u cumpurtamentu dinamica. U buttone hè nantu à € â € | u buttone ùn hè micca attivata; I micca decisu chè vocu à fà un cuadru statu di lu. Ma i classi uggettu ca hannu assai di u cumpurtamentu dinamica, mi sentu prubbabbirmenti puderà avè a taliari ni lu paisi di li uggetti.
Partu da mustrà un Statu, chi hè un triangulu tunna. I ponu avè stati principiu, e mi po ‘aviri stati riparu, chì sò fora, cum’è i cuglioni ochji. I pò ancu avè transitions tra stati, o transitions guardia (ciò chì succedi quannu sulu quannu un pattu è veru), o di ciò chì succede quannu sugnu dintra lu Statu. I look at Puiseux diagram e vedere i transition diagram Statu di una offerta corsu. Si cumencia in u statu di initialization, e mi dormire in chì statu finu à trasu un missaghju “”di cresce lu studenti””. Quannu trasu ca missaghju, mi misi u mio conti di studianti à zeru, è aghju prima di lu Statu Open. You Mulateri Di L’vede in Figure 14 ca ju nun haiu un avenimentu, e la ragiuni pirchì qualle ùn ci hè ca ju nun haiu dui maneri di escia ni ddu statu. Si dici ca nun avi mpurtanza comu vo site in u statu, mi vogghiu voi à fassi u studiente. Quandu I chjude è chì era statu lu canciamentu Dragoni à tene l ‘ombra di u numeru di i studienti si in lu corsu. I pò tene annuncià i studienti fin’a arrivare a 10, e poi vegnu cu vuiatri pi lu Close Statu. Na vota ca lu corsu hè avucatu, aghju prima di lu statu d ‘arrestu. No fastidiu, unni ju sugnu allura, si trasu lu passaggiu Annulla Event, I mintuvà u mio studienti è tandu prima di lu statu d ‘arrestu.
Di bassa uggettu ca hannu assai di u cumpurtamentu dinamica, qualle vali u colpu di fari ‘na m’agiterai Statu pè ottene una cala nantu à tuttu ciò chì hè à a succediri. Mi Manchi présenter nzo chi succèri quannu trasu un missaghju? Chi vùa fari ju, quannu trasu u missaghju? Cosa missaghji a aghju da mandà? Ci forri nu munzeddu di quelli missaghji divintatu u funziunamentu di i classi ‘uggettu, cum’è in stu esempiu unni aghjunghje un studiente hè un funziunamentu. Ci forri nu munzeddu di sti azzioni, comu pusannu li cunti, incrementing i conti, à cuntrollà lu cunti, sti tuttu diventa u funziunamentu privatu di ddu particulari di classi ‘uggettu e un m’agiterai Statu è unni nun vidu ca.
Comu sapiti s’è vo avete un tipu oggettu dinamica? Ancora na vota, pà vultà à u diagrams siquenza. Sè vo avete una classi oggettu chì hè nantu à una mansa di diagrams siquenza e lu in d’escia è di mandà un saccu di missaggi, chi l’una bona nfurmazzioni supra ch’ellu si trattava d’una volta à oggettu abbastanza giovani dinamichi è si duvia prubbabbirmenti hannu un cuadru statu di lu. Also di aggregations, unni vo avete u mondu di a so parti, u facciu un cuadru Statu per ogni sana aggregate. I fannnu sta prusu perchè chì tutta a aggregate hè spessu rispunsevuli di litturali di u messageria, chì parmetti di giovani dinamichi.
diagrams Sposa
Di sicuru, senza sistema pò esse custruitu, senza piglià in contu u munnu fisicu. Chì l’unni diagrams cumpunenti ghjuntu in casa. Iddi sunnu usati pi illustrate u urganisazione è dependencies à mezu à cumpunenti di software lìbbiru, macari cumpunenti còdice, cumpunenti tempu corri, o una cumpunenti executable. Cumpunenti si mostra cum’è un grande rectángulo cu dui caraìbe nica supra lu latu, comu vistu in Figure 15.
Figure 15: Elvetia
Ddi cosi annata chjare interfaccia (di solitu ciamati n’elimentu lecca lecca). In stu casu, si mostranu chì u Register.exe addipenni interfaccia a ntrammi li Course.dll è u People.dll. Chistu significa siddu sti interfaccia di canciari, si ti Algérienne u Register.exe. Ju sacciu ca c’è sta règula ci vo sunari costruzzioni interfaccia ca dici: “”chì tù ùn devi canciari l’interfaccia.”” Ma ùn a qualunqui intreccia u travagliu induve hè silenziu ca règula? Stu m’agiterai nni nzigna chi interfaccia sò aduprati solu da ciò chì executables sò in u mio lattaghju.
Figure 16: m’agiterai Java
Fà cresce UML
L’urtimu cosa ca vogghiu per sparghje circa li UML hè chì pò esse decise. Quannu si fici li UML, ch’elli assai li camurrìi di avvisti chì ci era nè manera sapianu creà una n’elimentu ca putissi piàciri tutti di la genti di tutti li tempi. So ci detti lu cuncettu di nu cacceti. A cacceti dici I pò piglià un elementu ppâ ricerca fundamentali è a dari lu cchiù significatu. Talianu pò ièssiri usatu a classify lu è d’ingrandà associ, e rilazione lascita, classi, e cumpunenti.
Figure 17: esempiu cacceti Web
Figure 17 ammustra lu m’agiterai di u nostru situ internet. A pàgina Web hà tipicamenti roba chì corre nant’à u vostru servore, è roba chì corre nantu à u cliente. Sè vo sunari costruzzioni appiicazioni Web-based, ciò chì d’corsa nantu à u vostru cliente, è u servore hè di mpurtanza vitali. Cusì avemu una tuttu ghjocu di Talianu chì mostranu chì. Lu picca roti rapprisèntanu cosi ca scurri nantu à u servore. So ghjustu par fighjulendu stu unu m’agiterai I pò vede ciò chì corre nantu à u servore, ciò chì corre nantu à u vostru cliente, è cum’elli sò prupitati ch’elli anu à guvernà.

“——————————————————————————————————————————————————

Podrška prijevod: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”The UML je standardni jezik za specificiranje, vizualizaciju, izgradnju i dokumentiranje sve artefakte softverski sustav.””
Dijagrami aktivnosti
Logično mjesto za početak hodanja kroz neke od UML dijagrama je gledajući dijagrame aktivnosti.
Slika 2: Dijagram aktivnosti
dijagrami aktivnosti prikazuju tijek kontrole. Kao što je prikazano na slici 2, možete vidjeti aktivnosti a predstavljaju zaobljenim pravokutnicima. Aktivnosti su obično akcijski stanja â € “”navodi da je tranzicija automatski na sljedeći stanje nakon akcije je završena. Ispunjeni krug predstavlja početak dijagrama aktivnosti â € “”gdje je protok kontrole počinje. Prijelazi su prikazani kao strelice pokazuju kako se kretati od aktivnosti na aktivnost. Usklađivanje barovi pokazati kako se aktivnosti događaju paralelno. Mogu čuvaju prijelaz koji kaže: “”Želim ići na ovu aktivnost samo ako to stanje je istina””, i mogu vam pokazati gdje se ne zaustavi. Sada, ako ste određene dobi, vjerojatno ćete pogledati ovaj dijagram aktivnosti i mislite, “”hmm â € |. Da izgleda kao dijagram toka”” I to je upravo ono što je, osim što ja ne radim to dolje na razini programiranja. Tipično, ja koristiti dijagram aktivnosti prilično rano u mom analiza i dizajn procesa pokazati radne okoline. Ja ću također koristiti ih pokazati gdje svaki od mojih slučajeva korištenja može biti u nekoj aktivnosti pokazati što se slučaj upotrebe mora dogoditi. Ja također koristiti dijagrami aktivnosti pokazati kako stvari teku između mojih namjena.
No, jedan od velikih stvari o UML je svestranost. Dakle, dok sam koristiti dijagrame aktivnosti na početku životnog ciklusa, drugi mogu ih koristiti u drugom fazom u cijelosti. Vidio sam ljudi koriste aktivnost shema dolje na razini dizajn gdje su imali vrlo kompliciran skup algoritama za određeni razred. A mnogi ljudi ih koristiti za prikaz toka između metodama klase.
sustav. Glumci su prikazani kao figure.
Slika 4: Glumci
Primjer koji sam radio za ovaj uvod u UML je malo model registracije Naravno sustava. Dakle, u ovom slučaju, prvo što ću učiniti kada počinju moja analiza je proces pitati “”, koji će se u interakciji s ovim sustavom?””
Za model registracije naravno, imam matičar, profesor i student. Također imam vanjski sustav naplate. Ovaj sustav naplate također kvalificira kao glumac. (Vidi, glumac ne mora biti osoba â € “”to je sve što se u interakciji sa sustavom, ali je izvan sustava).
Upotreba slučaj je slijed povezanih transakcija obavlja glumac u sustavu u dijalogu. Ili, da ga na engleskom, koristite slučaj je komad funkcionalnosti. I ovdje je ključ: to nije softverski modul â € “”to je nešto što daje vrijednost glumcu.
Koristite slučajevi su prikazani kao ovali, a najlakši način za pronaći ih je pogled na svaku od vaših glumaca i zapitajte se zašto žele koristiti sustav. U mom slučaju, moj matičar će održati nastavni plan i program, moj profesor će zatražiti spisak, moj student održava raspored, a moj sustav naplate prima informacije o naplati. Tako sam stvoriti svoje korištenje slučajevima gledajući na nju iz točke kupca gledišta i pita, “”pa, gospodine sustav glumac, zašto želite koristiti sustav? Koje vrijednosti se ovaj sustav pružiti za vas?””
Sljedeći korak, nakon što ste identificirali kako se akteri će biti u interakciji sa sustavom, je li dokument namjena. Svaki slučaj upotrebe treba dokumentirati tijek događaja, a to je učinjeno iz glumčeve gledišta. Trebalo bi detaljno što sustav mora osigurati da se glumac prilikom izvođenja korištenje slučaj. Obično to će pokazati informacije kao što je korištenje slučaj počinje i završava. Koje stvari to use slučaj ima veze? Vi ćete imati normalan tijek događaja (ono što ja nazivam scenarij “”sretnih dana””), gdje se sve radi. Tada ćete dobiti abnormalne tijek događaja, scenarij “”crne dane””. Što se događa kada sustav ne funkcionira? Našao sam dokumentirajući moj tijek događaja koji uvijek polaze sa sretni dani scenariju.
Uzmite kao primjer, hodanje i do Bankomat. Vi prošetati do bankomata i umetnite svoju karticu. Ona pita za PIN-a. Možete ga unijeti, a od vas se traži ono što želite učiniti. Kažeš: “”Želim nešto novca.”” Ona pita gdje je novac bi trebao biti uzeti iz. Možete ga reći da se to sa svog tekućeg računa. Ona pita koliko. Kažeš $ 100.00. Tada se događa magija â € | to vam daje $ 100.00. Onda je pita da li želite još jednu transakciju. Kažeš da ne. To vam daje svoju karticu natrag, daje vam potvrdu, a transakcija je gotova. To je sretan dan scenarij.
Drugi scenarij. Možete ići do bankomata, umetnite svoju karticu i unesite svoj PIN. ATM vam kaže da je to pogrešan PIN. Vi opet upisati svoj broj. Opet ste rekli da je PIN nije ispravan. Ti u mom naravno registraciju na primjer, na primjer, možete vidjeti da postoji puno “”ako X onda Y”” rada. To je mjesto gdje želite da vaš klijent koji će vam pomoći out. Dobivanje sporazum rano znači da je vaš klijent razumije ove scenarije i kaže: “”Da, to je ono što želimo.”” Koristite slučajevi su sjajan način kako bi se osiguralo da ono što gradi stvarno ono što kupac želi, jer pokazuju glumce, slučajevi uporabe, a odnose između njih.
Slika 5: Koristite slova dijagram
Dakle, imamo veliki crtež koji me što zorno pokazuje? Odgovor je jednostavan â € “”to je veliki dijagram koji pokazuje dobar pregled sustava. To pokazuje što je izvan sustava (glumaca) i funkcionalnosti koje sustav mora osigurati (primjere upotrebe). Ako postoji stari sustav morate uzeti u obzir, evo gdje se nositi s njim. Prisiljavanje me raditi s ovim vrstama sučelja vrlo rano u projektu znači da neću biti suočena s mogućnošću da čeka dok kodiranja počinje shvatiti kako ću razgovarati s tom crnu kutiju da se ne mogu mijenjati ,
Još jedna stvar koju treba znati o korištenju predmeta je realizacija upotreba slučaj. To je “”kako”” korištenja slučaj. To je obično kanta koja sadrži tri različite vrste dijagrama: dijagrami slijeda, dijagrama suradnje i klasa dijagram koji zovemo pogled nastave sudjeluju. Koristite slučaj realizacije su u osnovi način grupiranja broj predmeta koji se odnose na dizajn uporabu slučaju.
slijed Dijagrami
Slijed dijagrami prikazuju objekt interakcije raspoređenih u vremenskom slijedu. Mogu koristiti tijek događaja kako bi se utvrdilo što se predmeti i interakcije ću morati ostvariti funkcionalnost navede tijeka događaja.
Slika 6: Sequence dijagram
Slika 6 pokazuje kako je student uspješno dodaje na tečaj. Student (nazovimo ga Joe) ispunjava neke informacije i podnosi obrazac. Obrazac onda razgovara s upraviteljem i kaže “”dodaj Joe Math 101.”” Voditelj kaže Math 101 da to mora dodati učenik. Matematika 101 kaže stavku 1. “”jesi li otvorena?”” U tom slučaju, Odjeljak 1 odgovora da su otvoreni, tako Matematika 101 kaže odjeljak 1 da biste dodali ovaj student. Opet, dijagrami slijeda su velike alate u početku jer su vam i da vaš klijent pokazati korak po korak što se mora dogoditi.
Iz analize točke gledišta, pronašao sam tijekom godina da dijagrami slijeda su vrlo snažni u pomoć mene voziti zahtjeve; posebno zahtjevi koji su teško pronaći. Korisnički zahtjevi sučelje, na primjer, su notorne jer uvijek čini se da se zahtjevi koje su ne samo testirati. Čest UI uvjet kao što je to “”ovaj sustav će biti user-friendly””. Kako mnogi od vas su se susreli prijateljski računalo? Jedna od prednosti ove vrste dijagrama je da svaka linija dolazi od glumca koji predstavlja osobu, govori vam da se nešto u vašem UI mora osigurati sposobnost potrebnu ta osoba. Drugim riječima, možete koristiti dijagrami slijeda istjerati provjerljive zahtjeve korisničkog sučelja.
Slijed dijagrami su, dakle, odličan pokazatelj što se događa, za vožnju van zahtjeve, a za rad s klijentima. To obično dovodi do pitanja, ipak, koliko ti je potrebno za izradu? Moj odgovor je: “”sve dok ne učiniti dovoljno.”” Ideš saznati kada to učinite dijagrami slijeda da dođete do točke u kojoj ne možete pronaći nove predmete, ne nalazeći nove poruke, a da ste upisali istu stvar iznova i iznova. Na primjeru Joe pridružio Math 101, saznajemo da će se proces biti isti ako je Joe htio pristupiti History 101. Dakle, pravilo, napraviti dijagram slijeda za svaki osnovni protok svakom slučaju upotrebe. Da li dijagram sekvenci na visokoj razini, rizičnim situacijama, a to bi trebalo biti dovoljno. To je koliko slijed dijagrami i ja.
zapamtiti ovdje, je da dijagram suradnja je samo drugačiji pogled na scenariju, a možete otići natrag i naprijed između dijagrama sekvenci i dijagrama suradnje kako bi dobili prikaz koji najbolje ilustrira svoju točku.
Povremeno možete čuti izraz “”Dijagrami interakcije.”” Ponekad ljudi će kolektivno odnose na dijagramu suradnje i dijagram sekvenci kao interakcija dijagramu.
Klasa Dijagrami
Klasa je skup objekata sa zajedničkom strukturom, zajednički ponašanja, zajedničkih odnosa i zajedničkih semantike. Možete ih naći ispitivanjem predmeta u slijedu i suradnju dijagrami, i oni su zastupljeni u UML kao pravokutnik s tri odjeljka.
Slika 8: Klase
Prvi pretinac prikazuje naziv klase, drugi pokazuje njegovu strukturu (atribute), a treći pokazuje svoje ponašanje (operacija). Ovi odjeljci mogu se potisnuti, međutim, tako da možete vidjeti samo ime, samo ime i atribute, ili sva tri. Jedna stvar koju treba znati je da je važno, kod naziva klase, koristiti vokabular domene i odabrati standard. Na ovom slučaju, moje klase su svi jednine imenice koje počinju s velikim slovom. Vi svibanj izabrati da to učiniti drugačije, i to ne smeta. Što stvar je da je prije svog projekta Vas standard i držati s njim, tako da je sve u skladu preko projekta.
Klasa Dijagrami vam pokazati statičke prirode vašeg sustava. Ovi dijagrami pokazuju postojanje klasa i njihovih odnosa u logičkom pogledu sustava. Imat ćete mnogo klase dijagrame u modelu.
Elementi UML modeliranje naći u klasi dijagrama su:
Klase i njihova struktura i ponašanje.
Udruga, agregacije, zavisnosti, a nasljedstvo odnosa.
Mnoštva i navigacija pokazatelji
imena ulogu.
Bacite pogled na slici 9. Ovaj dijagram pokazuje operacije (ponašanje): što je predmet u tom razredu može učiniti. Ne mogu naći svoje poslovanje gledajući moje interakcije dijagrama.
Slika 9: Operacije
Ovdje govorim da moram biti u mogućnosti postaviti upravitelja registracija za dodavanje učenika u matematici
101. To će prevesti u operaciji pod nazivom “”addCourse””.
Struktura klase predstavljen svojim atributima. Pa kako mogu pronaći svoje atribute? U razgovoru za stručnjaka u određenom području. Gledajući na svojim zahtjevima. U mom primjeru, učim da svaki predmet ponuda ima broj, mjesto i vrijeme. Ovaj prevodi na tri atributa.
klase. (Zastupljeni u UML kao linija koja spaja srodne klase s dijamantom sljedećem razredu predstavlja cjelinu.)
â € ¢ Ovisnost â € “”slabija forma prikazuje odnos između klijenta i dobavljača u kojoj klijent nema semantičku poznavanje dobavljača. Ovisnost, kaže: “”Trebam svoje usluge, ali ne znam da postoje.”” (Zastupljeni u UML kao isprekidane linije upućuju od klijenta do dobavljača.)
Da biste pronašli odnose, još jednom, idem natrag u moj slijed dijagrama. Ako dva predmeta treba “”razgovarati””, mora postojati način da se to učini (tj odnos između svojih klasa).
Ja obično počinju i učiniti sve što je udruga. Kao što radim još analiza, možda ću pronaći Imam združivanja, jer ću morati brinuti o odnosu roditelj-dijete. Kad sam se u fazi projektiranja, saznam da nisam možda trebati udrugu zato što netko drugi će proći taj objekt u jednu od mojih metoda â € “”pa sam ga čine ovisnost.
Slika 11: Odnosi
Na slici 11 možete vidjeti te odnose. Kao udruga kaže profesor može razgovarati toku ponudu, a tečaj ponudi možete razgovarati s prof. Poruke se mogu pokrenuti i podaci mogu teći iz bilo kojeg smjera. Agregacija je prikazan tako da dijamant prema cijelom â € “”u ovom slučaju Tečaj se sastoji od kolegija. Razlog za to agregacije bi se reći svojim programere da ako se riješi ovaj tečaj, vjerojatno će morati učiniti nešto posebno s kolegija. Ovisnosti su prikazani kao isprekidanom linijom. To govori da je registracija manager ovisi o Popisu Algoritam nešto učiniti. Raspored Algoritam je bilo parametar jednom od metoda ili je proglašen lokalno jednom od metoda iz registracije Manager.
Mnogostrukost i navigacija
Mnoštvo definira kako mnogi objekti sudjeluju u vezi. To je broj primjeraka jedne klase vezane za jedan primjerak druge klase. Za svaku udruživanja i agregacije, postoje dva mnogostrukosti odluke kako bi: jedan za svaku kraja odnosa. Mnoštvo je predstavljena kao broj, a * koristi se predstavljaju raznolikost mnogih.
Slika 12: Mnogostrukost i navigaciju
Jedan profesor Predmet se odnosi na nula do četiri nudeći tečaj objekata. Jedan tečaj Ponuda Predmet je povezan s točno jednim profesorom objekt. Koristim ovo pogledati i osigurati da se to radi na moje zahtjeve. Mogu li biti ponudu za tečaj i biti timski uči hrpa profesora? Ne, jer to govori da mogu imati samo jedan profesor. Mogu li biti profesor i biti na studijske? Da, jer je to, kaže imam nulu kao mogućeg opterećenja kolegija. Koristim množinu vrlo često da mi pomogne započeli sa snimanjem i provedbi moje poslovnih pravila. Ako imate, na primjer, poslovni pravilo da kaže da mora imati najmanje 3 studentima i ne više od 10 za tečaj koji se nudi u semestru, te mnogostrukosti brojevi mi reći da sam registriran da poslovno pravilo u ovom planu.
Navigacija je prikazano strelicom, a iako udruge i zbirno su dvosmjerno po defaultu, često je poželjno ograničiti kretanje na jednom pravcu. Kad navigacija je ograničena, doda se strelice za označavanje navigacijske smjer. Jedna od stvari koje radim za vrijeme analize i dizajna faza je pogled na ono što želim da se uni-pravac. Stavljanjem na strelicu u ovom dijagramu, kažem da je Registar Manager može poslati poruku na teren, jer zna da postoji tečaj. No kolegija nema pojma da postoji Registracija Manager, tako da se, naravno, ne može pokrenuti poruku. Sada podataka može teći između njih; na primjer Registracija Manager može pitati, naravno, ako je otvorena, a naravno može se reći da je to. Ali samo registracija Manager može započeti taj razgovor.
Očito je cilj ovdje je da se što više strelice kao što možete u vrijeme kada ste završili projektiranje, jer je to mnogo lakše Sustav za održavanje Nasljeđivanje je prikazan s trokutom. To pokazuje da je profesor je registracija Korisničko jer je student. Sada, upozorenje. Nasljeđivanje je korisno, međutim, cilj je da ne koristi koliko baštinu vaš sustav će omogućiti. Vidio sam neke stvarno brutalne sustavima gdje su duboki imali nasljedna 17 razina. Ako su promijenili jednu stvar, on je postao katastrofa. Dakle, pravilo je da se koriste nasljedstva samo ako doista imate u baštinu situaciju.
Državni Prijelazni Dijagrami
Država prijelaz dijagram prikazuje povijest života u određenom razredu. To pokazuje događaje koji uzrokuju prijelaz iz jednog stanja u drugo, a akcije koje proizlaze iz promjene stanja.
Slika 14: Državni prijelaz dijagram
Koristim dijagrama prijelaza stanja za objekt klase koje obično imaju puno dinamičkog ponašanja. Gumb na â € | gumb isključen; Neću učiniti državni dijagram za to. No, objekt klase koje imaju puno dinamičko ponašanje, ja sam vjerojatno morati pogledati u stanja objekata.
Ja početi prikazivati stanje, što je zaobljena trokut. Ja mogu imati početak stanja, a ja mogu imati granične države, koji su prikazani kao bikova očiju. Ja također mogu imati prijelaza između stanja, ili čuvar prijelaza (stvari koje se događaju kad se samo kada je uvjet true), ili stvari koje se događaju kad sam unutar države. Gledam ovog dijagrama i vidjeti dijagram prijelaza stanja za tečaj ponude. Ona počinje u inicijalizacije stanju, a ja ostati u tom stanju sve dok se poruka “”dodaj student””. Kad sam dobiti tu poruku, JA postaviti moj broj studenta na nulu i sam prijelaz na otvorenom stanju. Vidjet ćete na slici 14 da imam ulaz, a razlog zašto je tu je da imam dva načina za dobivanje u toj državi. Ona kaže da bez obzira na to kako ste došli u stanje, želim se registrirati studenta. Kad sam izlaz da država, grof promjene pratiti broj studenata u tijeku. Ja mogu držati dodajući studente dok sam se do 10, a onda idem na Zatvori države. Nakon što je tečaj završen, ja prijelaz na stop stanju. Bez obzira na to gdje sam ja onda, ako ja dobiti Cancel doga prijelaz, ja o tome obavijestiti svoje studente, a zatim prijeći na stop stanju.
Za objekt klase koje imaju puno dinamičko ponašanje, to je dobro isplati napraviti dijagram stanja kako bi dobili handle na sve ono što se mora dogoditi. Zapitajte se što će se dogoditi kad dobijem poruku? Što da radim kad dobijem poruku? Koje poruke da moram poslati? Puno tih poruka postala operacije objekta klase, kao u ovom primjeru gdje dodali student je operacija. Puno tih radnji, kao što je postavljanje računati, povećavanjem računati, provjeri broj, svi oni postaju privatne operacije tog objekta klase i dijagram stanja je gdje sam vidjeti.
Kako ćete znati ako imate dinamičku objekt klase? Još jednom, vratiti na dijagramima slijed. Ako imate objekt klase koja je na puno dijagrama slijeda i to je sve i slanje puno poruka, to je dobar pokazatelj da je prilično dinamičan objekt klase i vjerojatno bi trebala imati državnu grafikona za to. Također za agregate, gdje imate cijelu njegovih dijelova, radim državni grafikon za svaki agregat cjelini. I to uglavnom zato da ukupna cijela je često odgovoran za upravljanje poruka, što ga čini dinamičan.
dijagrami Komponenta
Naravno, niti jedan sustav može biti izgrađen bez uzimanja u obzir fizički svijet. To je mjesto gdje komponenta dijagrami dolaze u. Oni se koriste za ilustraciju organizacije i ovisnosti među softverskih komponenti, uključujući i kod komponenti izvora, vrijeme izvođenja komponente, odnosno izvršnu komponentu. Komponente su predstave kao veliki pravokutnik s dva manja pravokutnika na strani, kao što se vidi na slici 15.
Slika 15: Komponente
Ti okrugle stvari predstavljaju sučelja (često se naziva lizalica označavanja). U ovom slučaju, oni pokazuju da Register.exe ovisi sučelja za oba Course.dll i People.dll. To znači da ako ta sučelja promijeniti, to će utjecati na Register.exe. Znam da je ovo pravilo kada izgradnji sučelja koja kaže “”ti neće promjeniti jezik sučelja.”” No, je li itko zapravo rade, gdje se provodi to pravilo? Ovaj dijagram nam govori što se sučelja koristi i izvršnih se izvodi na svojim procesorima.
Slika 16: Implementacija dijagram
Proširenje UML
Zadnja stvar koju želim naglasiti o UML je da se može produžiti. Kad su izgradili UML, mudro su shvatili da ne postoji način na koji bi mogli stvoriti zapis koji bi mogao zadovoljiti sve ljude sve vrijeme. Tako su nam dali koncept stereotipa. Stereotip kaže da mogu uzeti osnovni element za modeliranje i dati mu više značenja. Stereotipi mogu se koristiti za klasifikaciju i proširiti udruge, nasljeđivanja odnosa, nastava, i komponente.
Slika 17: Web stereotip primjer
Slika 17 prikazuje dijagram našim web stereotipa. Web-stranica obično ima stvari koje se izvodi na poslužitelju i stvari koje radi na klijenta. Ako ste izgradnju web-based aplikacije, što se izvodi na klijentu i poslužitelju je od vitalne važnosti. Dakle, imamo čitav niz stereotipa koje pokazuju da. Mali kotači predstavljaju stvari koje se izvršavaju na poslužitelju. Dakle, samo gleda u ovom jednom dijagramu mogu vidjeti što se izvodi na poslužitelju, što radi na klijentu, a što poslovni objekti imaju da se bave.

“——————————————————————————————————————————————————

Support oversættelse: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”The UML er den standard sprog til angivelse, visualisere, konstruere og dokumentere alle de artefakter af et software system.””
Aktivitetsdiagrammer
Den logiske sted at begynde at gå gennem nogle af UML diagrammer er ved at se på aktivitet diagrammer.
Figur 2: Aktivitet diagram
Aktivitet diagrammer viser strømmen af kontrol. Som illustreret i figur 2, kan du se aktiviteter repræsenteret afrundede rektangler. Aktiviteterne er typisk action hedder â € “”hedder det, at overgangen automatisk til næste tilstand efter handlingen er udført. Den udfyldte cirkel repræsenterer starten af aktiviteten diagrammet â € “”hvor strømmen af kontrol starter. Overgange vist som pile viser, hvordan du bevæger dig fra aktivitet til aktivitet. Synkronisering barer viser, hvordan aktiviteterne ske parallelt. Jeg kan beskytte en overgang, der siger “”Jeg vil have dig til at gå til denne aktivitet, hvis denne betingelse er sandt,”” og jeg kan vise dig, hvor det stopper. Nu, hvis du er en vis alder, vil du sandsynligvis se på denne aktivitet diagram og tænker, “”hmm â € |., Der ligner et flowchart”” Og det er præcis, hvad det er, bortset fra jeg ikke gør det ned på programmeringen niveau. Typisk bruger jeg en aktivitet diagram forholdsvis tidligt i min analyse og design proces for at vise business workflow. Jeg vil også bruge dem til at vise, hvor hver af mine use cases kan være i en aktivitet for at illustrere, hvad use case skal ske. Jeg bruger også aktivitet diagrammer til at vise, hvordan tingene flyde mellem mine use cases.
Men en af de store ting om UML er dens alsidighed. Så mens jeg bruger aktivitet diagrammer i begyndelsen af livscyklus, kan andre bruge dem i en anden fase helt. Jeg har set folk bruger aktivitet diagrammer ned på design niveau, hvor de havde en meget kompliceret sæt af algoritmer for en bestemt kategori. Og mange mennesker bruger dem til at vise flowet mellem metoder en klasse.
systemet. Skuespillere er repræsenteret som tændstikmænd.
Figur 4: Skuespillere
Det eksempel, som jeg arbejdede op for denne introduktion til UML er en lille model af et kursus registreringssystem. Så i dette tilfælde, det første, jeg ville gøre, når du starter min analyse er at spørge, “”hvem der skal interagere med dette system?””
For kursustilmelding model, jeg har en registrator, professor og en studerende. Jeg har også en ekstern faktureringssystem. Denne faktureringssystem kvalificerer også som skuespiller. (Se, en skuespiller behøver ikke at være en person, en € “”det er noget, der vekselvirker med systemet, men er uden for systemet.)
En use case er en sekvens af relaterede transaktioner, der udføres af en aktør i systemet i en dialog. Eller for at sige det på engelsk, en use case er en luns af funktionalitet. Og her er nøglen: Det er ikke et software-modul â € “”det er noget, der giver værdi til skuespilleren.
Brug sager er vist som ovaler, og den nemmeste måde at finde dem på er at se på hver af dine skuespillere og spørg dig selv hvorfor de ønsker at bruge systemet. I mit tilfælde er min registrator vil opretholde pensum, min professor vil anmode om en roster, min elev fastholder tidsplanen, og min faktureringssystem modtager informationen fakturering. Så jeg lave mine use cases ved at se på det fra kundens synspunkt og spørger, “”ja, Mister systemet skuespiller, hvorfor du ønsker at bruge systemet? Hvilken værdi har dette system giver dig?””
Det næste skridt, når du har identificeret, hvordan dine aktører vil blive interagere med systemet, er do dokumentere dine use cases. Hver use case skal dokumenteres med strømmen af begivenheder, og dette gøres fra skuespillerens synspunkt. Det skal detaljer, hvad systemet skal give skuespilleren når use case udføres. Det vil typisk vise ting som hvordan anvendelsen sagen starter og slutter. Hvilke ting betyder, at use case skal gøre? Du får den normale strøm af begivenheder (hvad jeg kalder “”glade dage”” scenario), hvor alt fungerer. Så får du den unormale strøm af begivenheder, den “”regnvejrsdag”” scenario. Hvad sker der, når systemet ikke virker? Jeg har fundet ved at dokumentere min strøm af begivenheder, som jeg altid starte med den lykkelige dag scenario.
Tag som eksempel, gå op til en pengeautomat. Du går op til ATM og indsætte dit kort. Det beder om din PIN-kode. Du indtaster det, og du bliver spurgt, hvad du gerne vil gøre. Du siger “”Jeg vil have nogle penge.”” Det spørger, hvor der bør tages pengene fra. Du fortæller det til at tage den fra din checkkonto. Det spørger hvor meget. Du siger $ 100,00. Så sker der magi â € | det giver dig $ 100,00. Så spørger, om du ønsker en anden transaktion. Du siger nej. Det giver dig dit kort tilbage, giver dig en kvittering, og transaktionen er slut. Det er den lykkelige dag scenario.
Andet scenario. Du går op til ATM, indsætte dit kort, og indtast din PIN-kode. ATM fortæller dig, det er den forkerte PIN-kode. Du indtaster dit nummer igen. Igen du får at vide, at PIN-koden er forkert. Du I mit kursustilmelding eksempel, for eksempel, kan du se, at der er en masse “”hvis X så Y”” arbejdsgange. Det er, hvor du vil have din kunde til at hjælpe dig ud. Kom aftale tidligt betyder, at din kunde forstår disse scenarier og siger “”ja, det er det, vi ønsker.”” Use cases er en fantastisk måde at sikre, at det, du bygger er virkelig, hvad kunden ønsker, fordi de viser aktørerne, use cases, og forholdet mellem dem.
Figur 5: Brug case diagram
Så vi har en stor diagram, der grafisk viser mig, hvad? Svaret er simpelt â € “”det er en stor diagram, der viser et godt overblik over systemet. Det viser, hvad der er uden for systemet (aktører) og funktionalitet, at systemet skal give (use cases). Hvis der er en arv system, du skal tage i betragtning, her er hvor du beskæftige sig med det. At tvinge mig til at arbejde med disse typer af grænseflader meget tidligt i projektet betyder, at jeg ikke vil blive konfronteret med udsigten til at vente, indtil kodning begynder at regne ud, hvordan jeg har tænkt mig at tale med denne sorte boks, som jeg ikke kan ændre .
En ting mere du bør vide om use cases er brugen tilfældet realisering. Dette er den “”hvordan”” af use case. Det er normalt en spand, som indeholder tre forskellige typer af diagrammer: sekvens diagrammer, samarbejde diagrammer, og en klasse diagram, som vi kalder en visning af deltagende klasser. Brug case erkendelser er dybest set en måde at samle en række artefakter vedrørende udformningen af en use case.
Sekvensdiagrammer
Sequence diagrammer viser objekt interaktioner arrangeret i en tid sekvens. Jeg kan bruge strømmen af begivenheder til at bestemme, hvad objekter og interaktioner jeg bliver nødt til at udføre de funktioner, angivet af strømmen af begivenheder.
Figur 6: Sekvens diagram
Figur 6 viser, hvorledes en studerende held bliver tilføjet til en kurs. Den studerende (lad os kalde ham Joe) udfylder nogle oplysninger og sender formularen. Skemaet taler derefter til manager og siger “”tilføj Joe til Math 101.”” Lederen fortæller Math 101, at det har at tilføje en studerende. Math 101 siger til § 1 “”er du åbner?”” I dette tilfælde, Afsnit 1 svar, at de er åbne, så Math 101 fortæller § 1 for at tilføje denne elev. Igen, sekvens diagrammer er gode værktøjer i starten, fordi de vise dig og din kunde trin-for-trin, hvad der skal ske.
Fra en analyse synspunkt har jeg fundet i løbet af de år, sekvens diagrammer er meget kraftige i at hjælpe mig drive krav; især krav, der er svære at finde. Brugergrænsefladen krav, for eksempel, er berygtet, fordi du altid synes at få krav, der er bare ikke testes. Et fælles UI krav som dette er “”systemet skal være brugervenligt.”” Hvor mange af jer har mødt en venlig computer? En af fordelene ved disse typer af diagrammer er, at hver linie, der kommer fra en skuespiller, der repræsenterer en person, fortæller dig, at noget i dit UI skal give en kapacitet nødvendig af denne person. Med andre ord, kan du bruge sekvensdiagrammer at køre ud testbare brugergrænseflade krav.
Sequence diagrammer er derfor god til at vise, hvad der foregår, for kørsel ud krav, og for at arbejde med kunder. Der normalt fører til spørgsmålet, selv om, hvor mange har du brug for at skabe? Mit svar er, “”indtil du gør nok.”” Du kommer til at finde ud af, når du gør sekvensdiagrammer, som du nå et punkt, hvor du ikke finde nogen nye objekter, ikke at finde nye beskeder, og at du skriver de samme ting igen og igen. I eksemplet med Joe sammenføjning Math 101, lærer vi, at processen ville være det samme, hvis Joe ønskede at slutte Historie 101. Så tommelfingerregel, gør en sekvens diagram for hver grundlæggende strøm af hver use case. Gør et sekvensdiagram for højt niveau, risikofyldte scenarier, og det burde være nok. Det er, hvor mange sekvens diagrammer jeg gør.
at huske her, er, at et samarbejde diagram er bare en anden opfattelse af et scenarie, og du kan gå frem og tilbage mellem sekvens diagrammer og samarbejde diagrammer for at få den opfattelse, at bedst illustrerer din pointe.
Lejlighedsvis, kan du høre sætningen “”interaktion diagrammer.”” Nogle gange vil folk kollektivt referere til et samarbejde diagram og en sekvens diagram som en vekselvirkning diagram.
klassediagrammer
En klasse er en samling af objekter med fælles struktur, almindelig adfærd, fælles relationer, og fælles semantik. Du finder dem ved at undersøge de objekter i sekvens og samarbejde diagrammer, og de er repræsenteret i UML som et rektangel med tre rum.
Figur 8: Klasser
Den første rum viser navnet klasse, den anden viser dets struktur (attributter), og den tredje viser sin adfærd (operationer). Disse rum kan undertrykkes, men så du kan se bare navnet, bare navn og attributterne, eller alle tre. En ting skal du også vide, er, at det er vigtigt, når navngivning klasser, for at bruge ordforråd af domænet og vælge en standard. For dette tilfælde mine klasser er alle ental navneord, der begynder med et stort bogstav. Du kan vælge at gøre det anderledes, og det gør ikke noget. Hvad betyder noget er, at før dit projekt du vælger en standard og holde sig til det, så alt er konsistent på tværs af projektet.
Klasse diagrammer vise dig den statiske karakter af dit system. Disse diagrammer viser eksistensen af klasser og deres relationer i den logiske opfattelse af et system. Du vil få mange klassediagrammer i en model.
De UML modellering elementer, der findes i klassediagrammer inkluderer:
Klasser og deres struktur og adfærd.
Association, sammenlægning, afhængighed, og arv relationer.
Mangfoldighed og navigation indikatorer
Rolle navne.
Tag et kig på figur 9. Dette diagram viser operationer (adfærd): hvad et objekt i denne klasse kan gøre. Jeg finder mine operationer ved at se på mine interaktioner diagrammer.
Figur 9: Operationer
Her er jeg sige, at jeg har brug for at være i stand til at spørge registreringen manager til at tilføje en studerende til matematik
101. Det kommer til at oversætte til en operation kaldet “”addCourse.””
Strukturen af en klasse er repræsenteret ved dets attributter. Så hvordan finder jeg mine attributter? Ved at tale til domæne eksperter. Ved at se på mine krav. I mit eksempel, jeg lære at hvert kursus tilbyder har et nummer, et sted, og en tid. Dette svarer ud til tre attributter.
klasser. (Repræsenteret i UML som en linie, som forbinder de relaterede klasser med en diamant ved siden af klassen som repræsenterer hele.)
â € ¢ Afhængighed â € “”en mildere form, der viser forholdet mellem en klient og en leverandør, hvor kunden ikke har semantisk kendskab til leverandøren. En afhængighed siger “”Jeg har brug for dine tjenester, men jeg ved ikke, at du eksisterer.”” (Repræsenteret i UML som en stiplet linie peger fra klienten til leverandøren.)
For at finde relationer, endnu en gang, jeg går tilbage til min sekvensdiagram. Hvis to objekter nødt til at “”tale””, skal der være et middel til at gøre det (dvs. et forhold mellem deres klasser).
Jeg starter typisk ud og gøre alt, hvad en forening. Som jeg gør mere analyse, kunne jeg finde jeg har en sammenlægning, fordi jeg har tænkt mig at skulle tage sig af en forældre-barn forhold. Når jeg kommer ind i designfasen, finder jeg ud af, at jeg ikke kan have behov for en forening, fordi en anden kommer til at passere, at objekt i en af mine metoder â € “”så jeg gør det en afhængighed.
Figur 11: Relationships
I figur 11 du ser disse relationer. Som forening siger professoren kan tale med kurset Udbuddet og Kursus Tilbyder kan tale til professor. Meddelelser kan initieres og data kan flyde fra alle retninger. Aggregation er vist ved at have diamant mod hele â € “”i dette tilfælde en kursus består af kursustilbud. Årsagen til denne sammenlægning ville være at fortælle mine udviklere, at hvis de slippe af med denne Course, vil de sandsynligvis nødt til at gøre noget særligt med kursustilbud. Afhængigheder er vist som en punkteret linie. Det siger, at registreringen leder afhænger af Schedule Algoritme til at gøre noget. Planlæg Algoritme er enten en parameter til en af metoderne eller erklæres lokalt af en af de metoder til registrering Manager.
Mangfoldighed og navigation
Mangfoldighed definerer, hvor mange objekter deltage i et forhold. Det er antallet af forekomster af en klasse relateret til en instans af den anden klasse. For de enkelte foreninger og sammenlægning, er der to mangfoldighed beslutninger at gøre: en for hver ende af forholdet. Multiplicitet er repræsenteret som et tal og en * bruges til at repræsentere en mangfoldighed af mange.
Figur 12: Mangfoldighed og navigation
Én Professor Object er relateret til nul-til-fire Kursus Tilbyder Objects. Et Kursus Tilbyder Object er relateret til nøjagtig en professor Object. Jeg bruger dette til at se på, og sikre, at dette håndterer mine krav. Kan jeg være et kursus Udbud og være hold-undervist af en flok af professorer? Nej, fordi det siger jeg kan kun have én professor. Kan jeg være en professor og være på orlov? Ja, fordi det siger jeg har en nul som muligt kursus belastning. Jeg bruger mangfoldighed ganske ofte til at hjælpe mig starte opfange og gennemføre mine forretningsregler. Hvis du har, for eksempel en virksomhed regel, der siger, at du skal have mindst 3 studerende og ikke mere end 10 for et kursus, der udbydes i et semester, disse mangfoldighed tal fortæller mig jeg har indarbejdet, at erhvervslivet regel i denne plan.
Navigation er vist med en pil, og selv om foreninger og aggregeringer er tovejs som standard, er det ofte ønskeligt at begrænse navigation til én retning. Når navigation er begrænset, tilføjes en pilespids for at angive navigations retning. En af de ting, jeg gør i løbet af analyse og design faser er at se på, hvad jeg ønsker at være ensrettede. Ved at sætte pilen ind i dette diagram, siger jeg, at registrering Manager kan sende en besked til kurset, fordi det ved eksisterer Course. Men Course har ingen idé om, at registrering manager eksisterer, så kurset kan ikke starte en besked. Nu data kan flyde mellem dem; for eksempel registrering manager kan bede Kursus hvis den er åben, og kurset kan sige, at det er. Men kun registrering Manager kan starte denne samtale.
Naturligvis mål her er at få så mange pile, som du kan med den tid, du er færdig med at designe, fordi det er en meget lettere system til at opretholde Nedarvning er vist med en trekant. Dette viser, at Professor er en registrering Bruger, som er Student. Nu, et ord af advarsel. Arv er nyttig, men målet er ikke at bruge så meget arv som dit system vil tillade. Jeg har set nogle virkelig brutale systemer, hvor de havde arve- 17-niveauer dybe. Hvis de ændret en ting, blev det en katastrofe. Så tommelfingerregel er at bruge nedarvning, når du virkelig har en arv situation.
State Transition diagrammer
En tilstandsovergangsdiagram viser livshistorie en given klasse. Det viser de begivenheder, der forårsager en overgang fra en tilstand til en anden, og de handlinger, der skyldes en tilstandsændring.
Figur 14: State overgang diagram
Jeg bruger state overgangseffekter diagrammer for objekt klasser, der typisk har en masse dynamisk adfærd. Knappen er på en € | knappen er slukket; Jeg har ikke tænkt mig at gøre en tilstand diagram for det. Men objektklasser der har en masse af dynamisk adfærd, jeg sandsynligvis nødt til at se på staterne i objekterne.
Jeg starter med at vise en tilstand, som er en afrundet trekant. Jeg kan have start- stater, og jeg kan have stop-stater, der er vist som tyre øjne. Jeg kan også have overgange mellem tilstande, eller vagt overgange (ting, der sker, når kun, når en betingelse er sand) eller ting, der sker, når jeg er inde i staten. Jeg ser på dette diagram og se staten overgangen diagram for et kursus tilbud. Det begynder i initialiseringen tilstand, og jeg ophold i denne tilstand, indtil jeg får en besked “”tilføj elev””. Når jeg får den besked, jeg indstille min optælling af studerende til nul, og jeg overgangen til Open tilstand. Du vil se i figur 14, at jeg har en post, og grunden til, at det er der, at jeg har to måder at komme ind i denne tilstand. Den siger, at uanset hvor du kommer ind i staten, jeg vil have dig til at registrere den studerende. Når jeg afslutter denne tilstand, at de tæller ændringer holde styr på antallet af studerende på kurset. Jeg kan holde tilføje elever, indtil jeg kommer til 10, og så skal jeg gå til Luk tilstand. Når kurset er afsluttet, jeg overgangen til stop tilstand. Uanset hvor jeg er så, hvis jeg får Annuller begivenhed overgang, jeg anmelde mine elever og derefter overgang til stop tilstand.
For objektklasser der har en masse af dynamisk adfærd, er det værd at gøre en tilstand diagram for at få styr på alt, hvad der skal ske. Spørg dig selv, hvad der sker, når jeg får en besked? Hvad gør jeg, når jeg får beskeden? Hvad beskeder til jeg har til at sende? En masse af disse meddelelser bliver driften af objektet klassen, som i dette eksempel, hvor tilføje en studerende er en operation. En masse af disse handlinger, såsom at indstille optællingen, forøgelse af tæller, kontrol greven, disse alle bliver private operationer af den pågældende objekt klasse og en tilstand diagram er, hvor jeg kan se, at.
Hvordan ved du, om du har et dynamisk objekt klasse? Igen, gå tilbage til sekvensen diagrammer. Hvis du har et objekt klasse, der er på en masse sekvensdiagrammer og det bliver og sende en masse beskeder, det er en god indikation, det er en temmelig dynamisk objekt klasse, og det skal nok have en tilstand diagram for det. Også for samlinger, hvor du har det hele af dens dele, jeg gør en tilstand diagram for hver samlet helhed. Jeg gør dette mest fordi det samlede helhed er ofte ansvarlig for at forvalte messaging, hvilket gør det dynamisk.
Komponent diagrammer
Naturligvis intet system kan bygges uden hensyntagen til den fysiske verden. Det er, hvor komponent diagrammer kommer i. De bruges til at illustrere de organisationer og afhængigheder mellem softwarekomponenter, herunder kildekode komponenter, køre tid komponenter eller en eksekverbar komponent. Komponenter er viser som et stort rektangel med to mindre rektangler på den side, som det ses i figur 15.
Figur 15: Komponenter
Disse runde ting repræsenterer grænseflader (ofte kaldet slikkepind notation). I dette tilfælde, de viser, at Register.exe er afhængig grænseflader til både Course.dll og People.dll. Det betyder, at hvis disse grænseflader ændres, vil det påvirke Register.exe. Jeg ved, at der er denne regel, når du bygger grænseflader, der siger “”du må ikke ændre grænsefladen.”” Men er der nogen rent faktisk arbejder, hvor denne regel håndhæves? Dette diagram fortæller os, hvad grænseflader bruges af hvilke eksekverbare kører på mine processorer.
Figur 16: Deployment diagram
Udvidelse UML
Det sidste, jeg ønsker at understrege om UML er, at det kan udvides. Da de byggede UML, de meget klogt indså, at der var ingen måde, de kunne skabe en notation, der kunne behage alle mennesker hele tiden. Så de gav os begrebet en stereotyp. En stereotype siger jeg kan tage en grundlæggende modellering element og give det mere mening. Stereotyper kan anvendes til at klassificere og udvide foreninger, arv relationer, klasser og komponenter.
Figur 17: Web stereotype eksempel
Figur 17 viser diagrammet af vores web-stereotyper. En webside har typisk ting, der kører på serveren og ting, der kører på klienten. Hvis du bygger web-baserede applikationer, hvad der kører på klienten og serveren er af afgørende betydning. Så vi har en hel række stereotyper, der viser, at. De små hjul repræsenterer ting, der kører på serveren. Så bare ved at kigge på denne ene diagram jeg kan se, hvad der kører på serveren, hvad kører på klienten, og hvilken branche objekter, de er nødt til at beskæftige sig med.

“——————————————————————————————————————————————————

Ondersteuning vertaling: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”De UML is de standaard taal voor het specificeren, visualiseren, construeren, en documenteren van alle artefacten van een software-systeem.””
Aktiviteitsdiagrammen
De logische plaats om te beginnen wandelen door een deel van de UML-diagrammen is door te kijken naar de activiteit diagrammen.
Figuur 2: Activiteit diagram
Activity diagrammen tonen de stroom van de controle. Zoals geïllustreerd in figuur 2, kan vertegenwoordigden als afgeronde rechthoeken zien. Activiteiten zijn meestal actie staten â € “”stelt dat de overgang automatisch naar de volgende staat na de actie is voltooid. De ingevulde cirkel de start van het stroomdiagram â € “”wanneer de stroom van besturing start. Transitions getoond als pijlen laten zien hoe je te verplaatsen van activiteit naar activiteit. Synchronisatie bars laten zien hoe activiteiten gebeuren in parallel. Ik kan een overgang die zegt te bewaken “”Ik wil dat je naar deze activiteit alleen als aan deze voorwaarde is waar,”” en ik kan je laten zien waar het stopt. Nu als je een bepaalde leeftijd bent, zul je waarschijnlijk kijken naar deze activiteit diagram en denken, “”hmm â € |. Dat eruit ziet als een stroomschema”” En dat is precies wat het is, behalve dat ik het niet doe neer op het niveau van de programmering. Typisch, gebruik ik een activiteit diagram vrij vroeg in mijn analyse en ontwerp proces om zakelijke workflow te tonen. Ik zal ze ook gebruiken om te laten zien waar elk van mijn use cases zou kunnen worden in een activiteit om te illustreren wat use case moet gebeuren. Ik gebruik ook de activiteit schema’s om te laten zien hoe de dingen stromen tussen mijn use cases.
Maar een van de grote dingen over de UML is zijn veelzijdigheid. Hoewel ik gebruik Activiteitsdiagrammen aan het begin van de levenscyclus, kunnen anderen ze in een andere fase volledig. Ik heb gezien dat mensen gebruiken Aktiviteitsdiagrammen neer op het ontwerp niveau waar ze hadden een zeer ingewikkelde set van algoritmen voor een bepaalde klasse. En veel mensen gebruiken ze om de doorstroming tussen de methoden van een klasse te tonen.
het systeem. Acteurs worden voorgesteld als poppetjes.
Figuur 4: Acteurs
Het voorbeeld dat ik werkte voor deze kennismaking met UML is een klein model van een cursus registratiesysteem. Dus in dit geval, het eerste wat ik zou doen als het starten van mijn analyse proces is om te vragen, “”wie gaat om te interageren met dit systeem?””
Voor de cursus registratie model, heb ik een registrar, een professor en een student. Ik heb ook een extern factureringssysteem. Dit billing systeem ook kwalificeert als acteur. (Zie, acteur hoeft niet iemand â € “”het iets dat samenwerkt met het systeem maar buiten het systeem).
Een use case is een samenhangende reeks van transacties uitgevoerd door een actor in het systeem in een dialoog. Of, om het in het Engels gezegd, een use case is een brok van functionaliteit. En hier is de sleutel: het is niet een softwaremodule â € “”het is iets dat waarde levert aan de acteur.
Use Cases zijn weergegeven als ovalen, en de makkelijkste manier om ze te vinden is om te kijken naar elk van uw acteurs en vraag jezelf af waarom willen ze het systeem te gebruiken. In mijn geval, mijn registrar gaat om het curriculum te behouden, mijn professor gaat om een rooster te vragen, mijn studententijd handhaaft de planning, en mijn billing systeem krijgt de factuurgegevens. Dus ik mijn use cases maken door er naar te kijken vanuit het oogpunt van de klant en vragen, “”dus, meneer systeem acteur, waarom zou je het systeem wilt gebruiken? Welke waarde heeft dit systeem aan u te leveren? ‘
De volgende stap, als je eenmaal hebt geïdentificeerd hoe uw spelers te maken krijgen met het systeem, is dat je je use cases documenteren. Elke use case moet worden gedocumenteerd met de stroom van gebeurtenissen, en dit wordt gedaan vanuit het oogpunt van de acteur. Het moet detail wat het systeem moet verstrekken aan de acteur als de use case wordt uitgevoerd. Typisch zal het dingen als hoe het use case begint en eindigt tonen. Welke dingen doet die use case te maken hebben? U zult het normale verloop van de gebeurtenissen (wat ik noem de “”happy days”” scenario), waar alles werkt hebben. Dan zult u de abnormale stroom van gebeurtenissen, de “”regenachtige dag”” scenario te krijgen. Wat gebeurt er als het systeem niet werkt? Ik heb ontdekt door het documenteren van mijn flow van gebeurtenissen die ik altijd beginnen met de gelukkige dagen scenario.
Neem als voorbeeld, oplopend naar een geldautomaat. Je loopt naar de ATM en plaats uw kaart. Het vraagt om uw pincode. U voert het, en u wordt gevraagd wat u zou willen doen. U zegt: “”Ik wil wat geld.”” Het vraagt waar het geld moet worden genomen van. Je vertellen dat het om het te nemen van uw bankrekening. Hij vraagt hoeveel. U zegt $ 100,00. Dan gebeurt er magic â € | het geeft je $ 100,00. Dan vraagt het als je een andere transactie wilt. Je zegt nee. Het geeft u uw kaart terug, geeft u een ontvangstbewijs, en de transactie is voorbij. Dat is de gelukkige dag scenario.
Tweede scenario. Je gaat naar de ATM, plaatst u de kaart en voer uw pincode. De ATM vertelt je dat het de verkeerde PIN-code. U geeft uw nummer opnieuw. Ook hier wordt verteld dat de PIN-code is onjuist. You In mijn cursus registratie bijvoorbeeld, bijvoorbeeld, kun je zien dat er een heleboel van “”als X dan Y”” workflows. Dat is waar u uw klant om u te helpen wilt. Krijgen overeenkomst betekent het begin van uw klant begrijpt deze scenario’s en zegt “”ja, dit is wat we willen.”” Use cases zijn een geweldige manier om ervoor te zorgen dat wat je aan het bouwen bent is echt wat de klant wil, omdat ze de acteurs, de use cases, en de relaties tussen hen te tonen.
Figuur 5: use case diagram
Dus hebben we een grote diagram die grafisch laat me wat? Het antwoord is simpel â € “”het is een geweldige diagram dat een goed overzicht van het systeem laat zien. Het laat zien wat er buiten het systeem (acteurs) en de functionaliteit die het systeem (use cases) moet verstrekken. Als er een legacy-systeem je nodig hebt om rekening te houden, hier is waar je mee omgaan. Dwingt me om te werken met dit soort interfaces heel vroeg in het project betekent dat ik niet zal worden geconfronteerd met het vooruitzicht van te wachten tot het coderen begint om erachter te komen hoe ik ga die zwarte doos die ik niet kan veranderen om te praten .
Nog een ding dat je moet weten over use cases is het use case realisatie. Dit is het ‘hoe’ van de use case. Het is meestal een emmer dat drie verschillende soorten diagrammen bevat: sequence diagrammen, samenwerkingsdiagrammen en een klassendiagram noemen wij een aanzicht van deelnemende klassen. Use case realisaties zijn in principe een manier groeperen een aantal voorwerpen in verband met het ontwerp van een use case.
Volgordediagrammen
Sequence diagrammen tonen object interacties gerangschikt in een tijdreeks. Ik kan de stroom van gebeurtenissen gebruiken om te bepalen welke objecten en interacties ik moet de functionaliteit die door de stroom van gebeurtenissen te bereiken.
Figuur 6: Sequence diagram
Figuur 6 toont hoe een student met succes wordt toegevoegd aan een cursus. De student (laten we noemen hem Joe) vult in wat informatie en stuurt het formulier. De vorm praat dan naar de manager en zegt: “”add Joe aan Math 101.”” De manager vertelt Math 101 dat het moet een student toe te voegen. Math 101 zegt, deel 1 “”bent u open?”” In dit geval, deel 1 antwoorden dat ze open, zodat Math 101 vertelt deel 1 van deze student toe te voegen. Nogmaals, sequence diagrammen zijn geweldige hulpmiddelen in het begin, omdat ze laten zien u en uw klant stap voor stap wat er moet gebeuren.
Uit een analyse oogpunt, heb ik geconstateerd door de jaren heen die sequence diagrammen zijn zeer krachtig in het helpen van me rijden eisen; vooral eisen die moeilijk te vinden zijn. User interface-eisen, bijvoorbeeld, zijn berucht omdat je altijd lijken te eisen die zijn gewoon niet toetsbaar te krijgen. Een veel voorkomende UI eis als dit is “”dit systeem moet gebruiksvriendelijk zijn.”” Hoeveel van jullie hebben een vriendelijke computer ontmoet? Een van de voordelen van dit soort schema is dat elke lijn uit een actor dat een persoon vertegenwoordigt, geeft aan dat iets in de gebruikersinterface heeft een vermogen nodig kunnen overleggen. Met andere woorden, u kunt sequence diagrammen gebruiken om toetsbare user interface-eisen te verdrijven.
Sequence diagrammen zijn dus goed voor het tonen van wat er gaande is, voor het verdrijven van eisen, en voor het werken met klanten. Dat leidt meestal tot de vraag, hoewel, hoeveel heb je nodig om te creëren? Mijn antwoord is, “”totdat je genoeg te doen.”” Je gaat om te weten wanneer je opeenvolgingsdiagrammen dat je een punt te bereiken waar u geen nieuwe objecten zijn te vinden, geen nieuwe berichten vinden te doen, en dat je hetzelfde typt over en voorbij. In het voorbeeld van Joe toetreding Math 101, leren we dat het proces hetzelfde zou zijn als Joe wilde History 101. Dus, vuistregel mee, doe een sequence diagram voor elke elementaire stroom van elke use case. Doe een sequence diagram voor high-level, risicovolle scenario’s, en dat moet genoeg zijn. Dat is hoeveel sequence diagrammen ik doe.
om te onthouden, is dat een samenwerking diagram is gewoon een andere kijk op een scenario en u kunt heen en weer gaan tussen sequence diagrammen en samenwerking schema’s tot de opvatting dat het best illustreert uw punt te krijgen.
Af en toe zou je hoort de term “”interactie diagrammen.”” Soms zullen mensen collectief verwijzen naar een samenwerking diagram en een sequence diagram als een interactie diagram.
klassediagrammen
Een klasse is een verzameling objecten met gemeenschappelijke structuur, gemeenschappelijke gedrag, gemeenschappelijke relaties en gemeenschappelijke semantiek. U vindt deze door onderzoek van de voorwerpen achtereenvolgens en collaboratiediagrammen en zij vertegenwoordigd in de UML als een rechthoek met drie compartimenten.
Figuur 8: Lessen
Het eerste compartiment wordt de naam van de klasse, de tweede toont de structuur (attributen), en de derde toont zijn gedrag (activiteiten). Deze compartimenten kunnen worden onderdrukt, echter, zodat je alleen de naam, alleen de naam en de kenmerken, of alle drie kunnen zien. Een ding moet je ook weten is dat het belangrijk is, bij het benoemen van de klassen, om de woordenschat van het domein gebruiken en kies een standaard. Voor dit geval, mijn lessen zijn allemaal enkelvoudige zelfstandige naamwoorden die beginnen met een hoofdletter. U kunt ervoor kiezen om het anders te doen, en dat doet er niet toe. Wat er wel toe doet, is dat voor uw project kunt een standaard te halen en vasthouden aan het zo dat alles is consistent in het project.
Class diagrammen tonen u de statische aard van uw systeem. Deze diagrammen tonen het bestaan van klassen en hun relaties in de logische weergave van een systeem. U zult vele class diagrammen in een model te hebben.
De UML-modellering elementen in klasse schema’s zijn onder andere:
Klassen en hun structuur en gedrag.
Association, aggregatie, afhankelijkheid, en overerving relaties.
Veelheid en navigatie indicatoren
Rolnamen.
Neem een kijkje op figuur 9. Deze figuur toont de bediening (gedrag): wat een object in die klasse kan doen. Ik vind mijn operaties door te kijken naar mijn interacties diagrammen.
Figuur 9: Operations
Hier ben ik te zeggen dat ik moet in staat zijn om de registratie manager vragen om een student om Math toe te voegen
101. Dat gaat vertalen in een operatie genaamd “”addCourse.””
De structuur van een klasse wordt weergegeven door de kenmerken. Dus hoe kan ik mijn attributen te vinden? Door te praten met domein experts. Door te kijken naar mijn eisen. In mijn voorbeeld, ik leren dat elke cursus aanbod heeft een aantal, een locatie, en een tijd. Dit vertaalt zich naar drie eigenschappen.
klassen. (Vertegenwoordigd in de UML als een lijn tussen de gerelateerde klassen met een diamant naast de klasse die het geheel.)
â € ¢ Afhankelijkheid â € “”een zwakkere vorm die de relatie tussen een klant en een leverancier waar de klant semantische kennis van de leverancier heeft. Een afhankelijkheid zegt: “”Ik heb uw diensten, maar ik weet niet dat je bestaat.”” (Vertegenwoordigd in de UML als een stippellijn wijzen van de client naar de leverancier.)
Om relaties te vinden, nogmaals, ga ik terug naar mijn sequence diagram. Als twee objecten nodig hebt om “”praten””, moet er een manier om dat te doen (dat wil zeggen, een relatie tussen hun klassen).
Ik begin meestal uit en maak alles een vereniging. Zoals ik doe meer analyses, zou ik vind ik een aggregatie, want ik ga te hebben om te zorgen voor een ouder-kind relatie. Toen ik in de ontwerpfase, vind ik dat ik een vereniging niet nodig heeft omdat iemand anders gaat dat object overgaan in een van mijn methoden â € “”dus ik maak er een afhankelijkheid.
Figuur 11: Relaties
In Figuur 11 zie je deze relaties. Als vereniging zegt de professor kan aan de cursus aanbieden, en het cursusaanbod praat met de professor kan praten. Berichten kunnen worden geïnitieerd en data kan stromen vanuit elke richting. Aggregatie wordt aangetoond door het hebben van de diamant in de richting van de hele â € “”in dit geval een cursus bestaat uit Course Offerings. De reden voor deze samenvoeging zou zijn om mijn ontwikkelaars vertellen dat als ze zich te ontdoen van deze cursus, zullen ze waarschijnlijk iets bijzonders met de Cursus Aanbod te doen. Afhankelijkheden worden weergegeven als een stippellijn. Het is te zeggen dat de registratie manager hangt af van de Schedule algoritme om iets te doen. Het schema algoritme is ofwel een parameter van een van de methoden of lokaal wordt aangegeven door een van de werkwijzen van de inschrijving Manager.
Multiplicity en navigatie
Multiplicity bepaalt hoeveel objecten deel te nemen aan een relatie. Het is het aantal instanties van een klasse verband met één exemplaar van de andere klasse. Voor elke vereniging en aggregatie, zijn er twee grote aantal beslissingen te maken: één voor elk uiteinde van de relatie. Multipliciteit wordt weergegeven als een getal en een * wordt gebruikt om een veelheid van verschillende vormen.
Figuur 12: Multipliciteit en navigatie
Eén Professor object is gerelateerd aan nul tot en met vier cursusaanbod Objects. Een cursus aanbieden object is gerelateerd aan precies één Professor Object. Ik gebruik deze om naar te kijken en ervoor zorgen dat deze handvatten mijn eisen. Kan ik een cursus aanbieden en zijn team-gegeven door een bos van professoren? Nee, want dat zegt dat ik kan slechts één professor. Kan ik een professor en worden op sabbatical? Ja, want dit zegt dat ik een nul als mogelijk studielast. Ik gebruik veelheid heel vaak om me te helpen beginnen met het vastleggen en uitvoeren van mijn business rules. Als u bijvoorbeeld een bedrijf regel die zegt dat je moet minimaal 3 studenten en niet meer dan 10 voor een cursus aan te bieden in een semester hebben, deze veelheid cijfers vertellen me dat ik heb opgenomen dat business rule in dit plan.
Navigatie wordt getoond door een pijl, en hoewel verenigingen en aggregaties zijn bi-directioneel standaard, is het vaak wenselijk om navigatie naar een richting te beperken. Wanneer de navigatie beperkt is, wordt een pijlpunt toegevoegd aan de navigatie-richting aan te geven. Een van de dingen die ik doe tijdens de analyse en ontwerp fase is kijken naar wat ik wil uni-directional te zijn. Door de pijl in dit schema, ik zeggen dat de Registratie Manager een bericht kan sturen naar de cursus, omdat het weet de cursus bestaat. Maar de cursus heeft geen idee dat de Registratie Manager bestaat, zodat de cursus kan een bericht niet starten. Nu data kan stromen tussen hen; bijvoorbeeld de registratie Manager kan de cursus vragen of het is geopend en de cursus kan zeggen dat het is. Maar alleen de Registratie Manager kan dat gesprek beginnen.
Het is duidelijk dat het doel is om zo veel pijlen te krijgen als je kunt tegen de tijd dat je klaar bent met het ontwerpen, want het is een veel eenvoudiger systeem om successierechten te handhaven wordt getoond met een driehoek. Dit toont aan dat de professor is een Registration gebruiker, net als de Student. Nu, een woord van waarschuwing. Overerving is nuttig, maar het doel is zoveel overerving systeem zal niet te gebruiken. Ik heb een aantal echt brute systemen waar ze erfdeel 17-niveaus diep gezien. Als ze één ding veranderd, werd het een ramp. Dus de vuistregel is om overerving alleen te gebruiken wanneer je echt wel een erfenis situatie.
State Transition Diagrams
Een staat transitie diagram toont het leven geschiedenis van een bepaalde klasse. Het toont de gebeurtenissen die een overgang veroorzaken van de ene staat naar de andere, en de acties die het gevolg zijn van een statuswijziging.
Figuur 14: State overgang diagram
Ik gebruik toestandsovergang’s voor objectklassen die hebben meestal een veel dynamisch gedrag. De knop is op â € | de knop uit; Ik ga niet naar een toestand grafiek voor doen. Maar object klassen die veel dynamisch gedrag te hebben, ben ik waarschijnlijk zal moeten kijken naar de toestand van de objecten.
Ik begin met een toestand toont, die een afgeronde driehoek. Ik kan start staten hebben, en ik kan stoppen staten, die worden weergegeven als de stieren ogen. Ik kan ook overgangen tussen staten, of guard overgangen (dingen die gebeuren wanneer alleen wanneer een voorwaarde waar is), of dingen die gebeuren als ik in de staat. Ik kijk naar dit diagram en zie de state transition diagram voor een cursus aanbieden. Het begint in de initialisatie staat, en ik blijf in die staat totdat ik een “”add student”” bericht. Toen ik die boodschap te krijgen, ik mijn telling van student tot nul en ik overgang naar de schuif open. Je ziet in figuur 14 dat ik een ingang, en de reden waarom het er is dat ik twee manieren om in die toestand. Het zegt dat het niet uitmaakt hoe je in de staat komen, ik wil dat je de student te registreren. Toen ik die toestand te verlaten, het aantal veranderingen bij te houden van het aantal studenten in de koers te houden. Ik kan blijven toevoegen studenten totdat ik tot en met 10, en dan ga ik naar de Close staat. Zodra de cursus is afgerond, ik overgang naar de halte staat. Het maakt niet uit waar ik ben dan, als ik het annuleren Event overgang, ik melden mijn studenten en vervolgens overgang naar de aanslag staat.
Voor object klassen die veel dynamisch gedrag hebben, het is zeker de moeite waard om een state diagram om greep te krijgen op alles wat er moet gebeuren doen. Vraag jezelf af wat er gebeurt als ik een bericht te krijgen? Wat moet ik doen als ik het bericht? Wat berichten naar ik heb te sturen? Veel van deze berichten worden die van de objectklasse, zoals in dit voorbeeld waar voeg student een operatie. Veel van deze acties, zoals het instellen van de telling, het verhogen van de telling, het controleren van de graaf, deze worden allemaal een eigen verrichtingen van dat specifieke object-klasse en een state diagram is waar ik dat zie.
Hoe weet u of u een dynamisch object-klasse? Nogmaals, ga terug naar de sequence diagrammen. Als u een object klasse die er op veel opeenvolgingsdiagrammen en het ophalen en verzenden van een veel berichten, dat is een goede indicatie dat het een vrij dynamisch object klasse en het zou waarschijnlijk een state grafiek voor het. Ook voor combinaties, waar je het geheel van zijn delen, doe ik een staat grafiek voor elk aggregaat geheel. Ik doe dit vooral omdat dat aggregaat geheel is vaak verantwoordelijk voor het beheer van de messaging, waarin het dynamisch maakt.
component diagrammen
Vanzelfsprekend geen systeem kan worden opgebouwd zonder rekening te houden met de fysieke wereld. Dat is waar component diagrammen komen. Ze worden gebruikt om de organisaties en afhankelijkheden te illustreren tussen software componenten, inclusief broncode componenten, looptijd componenten, of een uitvoerbaar component. Componenten zijn toont als een grote rechthoek met twee kleinere rechthoeken aan de zijkant, zoals in figuur 15.
Figuur 15: Componenten
Die ronde dingen vertegenwoordigen interfaces (vaak genoemd lollipop notatie). In dit geval, tonen zij dat de Register.exe is afhankelijk interfaces voor zowel de Course.dll en People.dll. Dat betekent dat als deze interfaces worden gewijzigd, zal de Register.exe beïnvloeden. Ik weet dat er deze regel als je het bouwen van interfaces die zegt: “”gij zult de interface niet veranderen.”” Maar heeft iemand eigenlijk werken waar die regel wordt nageleefd? Dit schema vertelt ons wat interfaces worden gebruikt door wat executables draaien op mijn processors.
Figuur 16: Deployment diagram
Uitbreiding van UML
Het laatste wat ik wil benadrukken de UML is dat het kan worden verlengd. Toen zij de UML gebouwd, dat ze heel verstandig besefte dat er op geen enkele manier konden ze een aantekening dat alle mensen konden behagen de hele tijd te maken was. Dus gaven ze ons het concept van een stereotype. Een stereotype zegt dat ik een fundamenteel element modeling te nemen en geven meer betekenis. Stereotypen kunnen worden gebruikt om te classificeren en uit te breiden verenigingen, erfenis relaties, klassen en componenten.
Figuur 17: Web stereotype voorbeeld
Figuur 17 toont het schema van onze website stereotypen. Een webpagina heeft meestal dingen die draait op de server en dat soort dingen, dat draait op de client. Als je het bouwen webgebaseerde applicaties, wat draait op de client en de server is van vitaal belang. Dus hebben we een hele reeks van stereotypen die dat aantonen. De kleine wielen vertegenwoordigen dingen die draaien op de server. Dus gewoon door te kijken naar deze ene diagram ik kan zien wat draait op de server, wat draait op de client, en wat het bedrijfsleven objecten die ze moeten behandelen.

“——————————————————————————————————————————————————

Podpora překladu: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”UML je standardní jazyk pro specifikaci, vizualizaci, konstrukci a dokumentovat všechny artefakty softwarového systému.””
Aktivita Diagramy
Logické místo, kde začít procházel některé z UML diagramů je při pohledu na diagramy aktivit.
Obrázek 2: Aktivita diagram
diagramy aktivit ukazují tok řízení. Jak je znázorněno na obrázku 2, můžete vidět aktivity reprezentován jako zaoblené obdélníky. Aktivity jsou typicky akční stavy â € “”se uvádí, že přechod automaticky do dalšího stavu poté, co akce je kompletní. Vyplněný kruhu představuje začátek diagramu aktivit â € “”, kde tok kontrolních startů. Přechody znázorněné jako šipky ukazují, jak budete pohybovat od aktivity k aktivitě. Synchronizační bary ukazují, jak činnost stane paralelně. Mohu hlídat přechod, který říká: “”Chci, abys šel do této činnosti pouze tehdy, pokud je tato podmínka pravdivá,”” a já vám ukázat, kde se zastaví. Nyní, když jste určitého věku, pravděpodobně budete vypadat v tomto diagramu aktivit a přemýšlet, “”hmm â € |., Který vypadá jako diagramu”” A to je přesně to, co to je, s výjimkou Nedělám ho na programové úrovni. Typicky, já používám diagramu aktivit poměrně brzy v mém analýzu a návrh procesu ukázat pracovním postupům. Budu také používat je, aby ukázal, kde každý z mých případů použití by mohl být do činnosti pro ilustraci k čemu případ se musí stát. Já také použít diagramy aktivit ukázat, jak se věci proudit mezi mými případy užití.
Ale jeden z velkých věcí, o UML je jeho univerzálnost. Takže i když jsem použít diagramy aktivit na začátku životního cyklu, ostatní mohou používat je v jiné fázi úplně. Viděl jsem lidé používají aktivita diagramy dolů na úrovni designu, kde měli velmi složitý soubor algoritmů pro určitou třídu. A mnoho lidí využívá k zobrazování tok mezi metodami třídy.
systém. Herci jsou reprezentovány jako čísla tyče.
Obrázek 4: Herci
Příklad že jsem pracoval pro tento úvod do UML je malý model registračního Samozřejmě systému. Takže v tomto případě, první věc, kterou bych udělal, když začíná moje analýza proces je se ptát, “”kdo bude komunikovat s tímto systémem?””
Pro registraci modelu samozřejmě, mám registrátora, profesorem a studentem. Mám také externí účtovací systém. Tento platební systém také kvalifikuje jako herec. (Viz, herec nemusí být osoba, â € “”to je něco, který spolupracuje se systémem, ale je mimo systém).
Použití případ je posloupnost souvisejících transakcí provedených účastníkem v systému v dialogovém okně. Nebo, řečeno v angličtině, je případ užití je kus funkčnosti. A tady je klíč: to není softwarový modul â € “”to je něco, který poskytuje hodnotu pro herce.
Případy užití jsou zobrazeny jako ovály, a nejjednodušší způsob, jak je najít, je podívat se na každé ze svých herců a zeptejte se sami sebe, proč vlastně chtějí používat systém. V mém případě, moje registrátor bude udržovat osnov, můj profesor se chystá požádat o seznam, můj student udržuje plán a moje fakturační systém přijímá fakturačních údajů. Tak jsem vytvářet své případy použití při pohledu na to z pohledu zákazníka a žádají, “”ano, pane systém herec, proč chcete použít systém? Jakou hodnotu má tento systém poskytnout vám?””
Dalším krokem, jakmile jste se identifikovat, jak se vaše herci budou v kontaktu se systémem, zní, zda dokumentovat své případy použití. Každý případ použití musí být dokumentovány s proudem událostí, a to se provádí z bodu herce pohledu. Mělo by detail toho, co systém musí poskytnout herce, když je případ užití vykonán. Typicky to ukáže věci, jako jak začíná a končí užívání případ. Jaké věci to, že případ užití má dělat? Budete mít normální tok událostí (to, čemu říkám “”Happy Days”” scénář), kde všechno funguje. Pak budete mít abnormální tok událostí, na “”horší časy”” scénář. Co se stane, když systém nepracuje? Zjistil jsem, dokumentováním svůj tok událostí, které jsem vždy začít s šťastné dny scénáře.
Jako příklad, chůze a to až do bankomat. Budete chodit do bankomatu a vložte kartu. To vyzve k zadání vašeho čísla PIN. Můžete zadat to, a budete dotázáni, co byste chtěli dělat. Říkáte “”Chci nějaké peníze.”” To se zeptá, kde peníze by měly být odebrány. Můžete říct, že to brát ze svého běžného účtu. To se ptá, jak moc. Říkáte $ 100,00. Pak magie stane, â € | dává vám $ 100,00. Pak se zeptá, zda chcete jinou transakci. Říkáte, že ne. To vám dává svou kartu zpět, dá vám stvrzenku, a transakce je u konce. To je ten šťastný den scénář.
Druhý scénář. Jdete do bankomatu, vložte kartu a zadejte svůj PIN. ATM vám řekne, že je to špatný PIN. Můžete zadat znovu své číslo. Opět jste řekl, že kód PIN je nesprávný. Vy V mém kurzu Registrace Například, například, můžete vidět, že existuje spousta “”Jestliže X, pak Y”” pracovními postupy. To je místo, kam chcete své zákazníky, aby vám pomohl ven. Získání dohoda brzy znamená, že váš zákazník chápe tyto scénáře a říká: “”Ano, to je to, co chceme.”” Případy užití jsou skvělý způsob, jak zajistit, že to, co stavíte je opravdu to, co zákazník chce, protože ukazují herce, případy použití, a vztahy mezi nimi.
Obrázek 5: diagram užití
Takže máme velký diagram, který mi to, co je graficky znázorněna? Odpověď je jednoduchá â € “”to je skvělý diagram, který ukazuje dobrý přehled o systému. To ukazuje, co je vně systému (herci) a funkce, které systém musí poskytovat (případy užití). Pokud existuje starší systém, který je třeba vzít v úvahu, tady je místo, kde jste se s tím vyrovnat. Nutí mě k práci s těmito typy rozhraní velmi brzy v projektu znamená, že nebudu potýkají s vyhlídkou na čekat, až kódování začne přijít na to, jak budu mluvit k tomuto černou skříňku, že nemohu změnit ,
Ještě jedna věc, kterou byste měli vědět o případech použití je realizace použití případ. Jedná se o “”jak”” využívání případ. Je to obvykle kbelík, který obsahuje tři různé druhy diagramů: sekvenčních diagramů, spolupráce diagramy a třída diagram, který nazýváme výhled zúčastněných tříd. Use case realizace jsou v podstatě způsob, jak sdružující řadu artefaktů vztahujících se k návrhu případu užití.
vývojových diagramů
Sekvenční diagramy ukazují interakce objektů uspořádané v časové posloupnosti. Mohu použít tok událostí zjistit, jaké předměty a interakce I bude muset dosáhnout funkce specifikované toku událostí.
Obrázek 6: Sekvenční diagram
Obrázek 6 ukazuje, jak student úspěšně dostane přidáno do kurzu. Student (říkejme mu Joe) vyplní nějaké informace a odešle formulář. Formulář pak mluví s manažerem a říká: “”přidat Joe Math 101.”” Správce říká matematický 101, že má přidat studenta. Math 101 říká, že § 1 “”máte otevřeno?”” V tomto případě, Sekce 1 odpovědí, že jsou otevřené, takže matematický 101 říká, oddíl 1 přidat tento student. Opět platí, že sekvenční diagramy jsou skvělé nástroje na začátku, protože vy a váš zákazník ukáže krok za krokem, co se stane.
Z analýzy pohledu jsem zjistil, za ta léta, že sekvenční diagramy jsou velmi silné v mi pomáhají řídit požadavky; zejména požadavky, které jsou těžko k nalezení. Požadavky na uživatelské rozhraní, například, jsou notoricky známé, protože jste vždycky dostat požadavky, které prostě nejsou testovatelné. Běžným požadavkem UI, jako je to “”tento systém musí být uživatelsky příjemný.”” Jak mnozí z vás se setkal s přátelskou počítač? Jednou z výhod těchto typů grafů je, že každý řádek pocházející z herce, který představuje osobu, vám řekne, že něco ve svém uživatelském rozhraní musí zajistit možnost potřebnou touto osobou. Jinými slovy, můžete použít sekvenční diagramy vyhnat testovatelné požadavky uživatelského rozhraní.
Sekvenční diagramy jsou proto vhodné pro ukazuje, co se děje, protože vyhánět požadavky, a pro práci se zákazníky. Které obvykle vede k otázce, i když, jak mnoho z nich je třeba vytvořit? Moje odpověď je, “”dokud vy dost.”” Budeš zjistit, kdy děláte sekvenční diagramy, které se dostanete do bodu, kdy už nemůže najít žádné nové objekty, ne nacházet žádné nové zprávy, a že jste psát to samé pořád dokola. V příkladu Joe spojování Math 101 se dozvídáme, že tento proces by byl stejný, pokud Joe chtěl vstoupit do historie 101. Takže pravidlo, dělat sekvenční diagram pro každou základní tok každém případě užití. Proveďte sekvenční diagram na vysoké úrovni, rizikové scénáře, a to by mělo stačit. To je to, kolik sekvence diagramy já.
třeba pamatovat, je, že spolupráce diagram je jen jiný pohled na situaci a můžete jít tam a zpět mezi sekvenčních diagramů a diagramů spolupráce se dostat k názoru, že nejlépe ilustruje své místo.
Občas můžete slyšet frázi “”interakce diagramy.”” Někdy se lidé budou společně odkazovat na diagramu spolupráce a sekvenční diagram jako interakčního diagramu.
diagramů tříd
Třída je kolekce objektů se společnou strukturou, společné chování, běžné vztahy a společné sémantiky. Naleznete je tím, že zkoumá objekty v pořadí a spolupráce diagramů, a jsou zastoupeny v UML jako obdélník se třemi přihrádkami.
Obrázek 8: Třídy
První přihrádka zobrazuje název třídy, druhý ukazuje jeho strukturu (atributy), a třetí ukazuje jeho chování (operace). Tyto prostory mohou být potlačeny, nicméně, takže můžete vidět jen název, ale pouze název a atributy, nebo všechny tři. Jedna věc, kterou byste měli také vědět, je, že je důležité, při pojmenovávání tříd, používat slovní zásobu domény a vybrat standard. Pro tuto instanci mé třídy jsou všechny singulární podstatná jména, která začínají velkým písmenem. Můžete si vybrat, jak to udělat jinak, a to nevadí. Co ohledu na to, je to, že dříve, než váš projekt si vyberete úroveň a držet se ho tak, že všechno je konzistentní napříč projektu.
Třída Diagramy ukázat vám statickou povahu vašeho systému. Tyto diagramy ukazují na existenci tříd a jejich vztahů v logickém pohledu systému. Budete mít mnoho diagramy tříd v modelu.
V UML modelování prvky nalezené v diagramů tříd patří:
Třídy a jejich struktura a chování.
Sdružení, agregace, závislost, a dědické vztahy.
Mnohosti a navigační indikátory
Jména roli.
Podívejte se na obrázku 9. Toto schéma ukazuje operací (chování): co je objekt v této třídě se dá dělat. Zjistil jsem, moje operace při pohledu na mé interakce diagramů.
Obrázek 9: Provoz
Zde Říkám, že musím mít možnost požádat správce registrační přidat studenta k Math
101. To bude překládat do provozu s názvem “”addCourse.””
Struktura třídy je reprezentován jeho atributů. Tak jak najdu své atributy? Tím, že mluví odborníků domény. Při pohledu na moje požadavky. V mém příkladu jsem se dozvěděl, že každý kurz oběť má číslo, místo a čas. To se projevuje mimo tři atributy.
třídy. (Zastoupeny v UML jako čára spojující příslušné třídy s diamantem vedle třídy, jež představuje celek.)
â € ¢ Závislost â € “”jemnější formou znázorňující vztah mezi klientem a dodavatelem, kdy klient nemá sémantický znalostí dodavatele. Závislost říká “”já potřebuji vaše služby, ale nevím, že jste existují.”” (Zastoupeny v UML jako přerušovaná čára směřující od zákazníka na dodavatele.)
Chcete-li najít vztahy, opět jsem se vrátit do svého sekvenční diagram. Pokud se dva objekty potřebují “”mluvit””, musí existovat prostředky, aby tak učinily (tj vztah mezi jejich třídami).
I obvykle začínají ven a dělat všechno sdružení. Jako dělám víc analýzy, mohl bych najít mám agregaci, protože budu muset postarat o vztahu mezi rodičem a dítětem. Když jsem se dostal do fáze návrhu, jsem zjistil, že jsem nemusí potřebovat sdružení, protože někdo jiný se chystá předat tento objekt do jednoho z mých metod € “”, takže jsem ji činí závislost.
Obrázek 11: Vztahy
Na obrázku 11 vidíte tyto vztahy. Jako sdružení říká profesor může mluvit s průběhem oběti a Nabıdky kurzu může mluvit s profesorem. Zprávy mohou být zahájeny a data mohou proudit z jakéhokoliv směru. Agregace je zobrazen tím, že diamant směrem k celé â € “”v tomto případě Kurz se skládá z nabídky kursu. Důvodem pro toto seskupení by bylo říci svým vývojářům, že pokud se zbavit tohoto kurzu, budou pravděpodobně muset udělat něco speciálního s Nabídka kurzů. Závislosti jsou zobrazeny jako přerušovaná čára. To říká, že manažer registrace závisí na plán algoritmu něco udělat. Schedule Algoritmus je buď parametrem pro jednu z metod, nebo je prohlášen lokálně jednou z metod Registrační Manager.
Rozmanitost a navigace
Multiplicita určuje, kolik objektů se účastní ve vztahu. To je počet instancí jedné třídy týkajících se jednoho instance jiné třídy. Pro každou asociaci a agregaci, jsou zde dvě multiplicita rozhodnutí o poskytnutí: jeden na každém konci vztahu. Multiplicita je reprezentován jako číslo a * se používá k reprezentaci multiplicity z mnoha.
Obrázek 12: Multiplicity a navigace
Jeden profesor objekt souvisí s nulovým až čtyři Nabízet Course objektů. Jeden kurz nabízet objekt souvisí s přesně jeden profesora objektu. Používám to na pohled a zajistit, aby tato zpracovává mé požadavky. Mohu být k oběti kurz a bude team-učil banda profesorů? Ne, protože to říká, že může mít pouze jeden profesor. Mohu být profesor a být na volno? Ano, protože to říká, že mám nulu jako možného zatížení kurzu. Já používám mnohost poměrně často, aby mi pomohl začít zachycovat a provádění své obchodní pravidla. Pokud máte například obchodní pravidlo, které říká, že musí mít alespoň 3 studenty a ne více než 10 o kurzu, které budou nabízeny v semestru, tato čísla multiplicity mi říkají, že jsem začleněny, že obchodní pravidla do tohoto plánu.
Navigace je znázorněno šipkou, a ačkoli asociace a agregace jsou obousměrné ve výchozím nastavení, je často žádoucí omezit plavbu jedním směrem. Je-li navigační omezen, hrotu šípu se přidává k označení navigační směr. Jedna z věcí, které jsem dělat během analýzy a návrhu etap, je podívat se na to, co já chci být jednosměrná. Tím, že na šipku do tohoto schématu, říkám, že registrační Manager může poslat zprávu na hřiště, protože ví, že existuje Course. Ale Předmět nemá tušení, že existuje registrační manažer, takže kurz nemůže iniciovat zprávu. Nyní data mohou proudit mezi nimi; Například může Registrace správce požádat Samozřejmě, pokud je to otevřené a kurz může říci, že je. Ale jen Registrační Manager může začít tento rozhovor.
Je zřejmé, že cílem je získat co nejvíce šípů, jak můžete v době, kdy jste skončil projektování, protože je to mnohem jednodušší systém udržovat dědičnost je zobrazen s trojúhelníkem. To ukazuje, že profesor je registrace uživatele, jako je Student. Nyní slovo varování. Dědičnost je užitečná, ale cílem není pouze tolik dědictví jako váš systém umožní. Viděl jsem nějaké opravdu brutální systémy, kde měli dědičnosti 17 úrovní hluboko. Pokud se změnila jednu věc, to se stalo katastrofa. Takže pravidlem je používat dědičnost pouze tehdy, pokud opravdu mají k situaci dědičnosti.
Stavový přechod Diagramy
Státní přechodový diagram ukazuje životní příběh danou třídu. To ukazuje události, které způsobují přechod z jednoho stavu do druhého, a akce, které vyplývají ze změny stavu.
Obrázek 14: Státní přechodový diagram
Já používám stavový přechod diagramy pro třídy objektů, které obvykle mají hodně dynamické chování. Tlačítko je na â € | tlačítko je vypnutý; Nebudu dělat stavový diagram pro něj. Ale třídy objektů, které mají hodně dynamického chování, budu pravděpodobně bude muset podívat do stavů objektů.
Začnu tím, že ukazuje stav, který je zaoblený trojúhelník. Mohu mít počáteční stavy, a můžu mít uzavírací stavy, které jsou zobrazeny jako býky očí. Mohu mít také přechody mezi státy nebo ochranného přechody (věci, které se přihodí, když pouze tehdy, pokud je splněna podmínka), nebo věci, které se přihodí, když jsem uvnitř státu. Dívám se na tomto diagramu a podívejte se na přechodu stavu diagram na kurz nabídkami. Začíná ve stavu inicializace, a já zůstat v tomto stavu, dokud jsem si zprávu “”přidat studenta””. Když jsem si tu zprávu jsem nastavil svůj počet studentů na nulu a já přechod do otevřeného stavu. Uvidíte na obrázku 14, že mám povolení ke vstupu, a důvod, proč je to tam je, že mám dva způsoby, jak dostat do tohoto stavu. To říká, že bez ohledu na to, jak jste přišel do stavu, chci, abyste registrovat studenta. Když jsem se opustit tento stav, počet změn k udržení přehledu o počtu studentů v kurzu. Mohu držet přidání studenty, dokud jsem si na 10 a pak jdu do Close stavu. Jakmile je kurz je dokončen, já přechod do stavu zastavení. Bez ohledu na to, kde jsem tehdy, když jsem si Cancel přechod případě jsem oznámit svým studentům a poté přejít do stavu zastavení.
U tříd objektů, které mají hodně dynamické chování, je to také stojí za to udělat stavový diagram získat handle na vše, co se musí stát. Zeptejte se sami sebe, co se stane, když se zobrazí zpráva? Co mám dělat, když dostanu zprávu? Co zpráv mám poslat? Mnoho z těchto zpráv stávají operace třídu objektu, jako v tomto příkladu, kde přidat student je operace. Mnoho z těchto akcí, jako je nastavení počtu, postupně počítání, kontrola počtu, tito všichni stanou soukromé operace danou třídu objektu a stavový diagram je místo, kde to vidím.
Jak víte, pokud máte dynamickou třídu objektů? Opět se vrátit do sekvenčních diagramů. Máte-li třídu objektů, který je na mnoha sekvenčních diagramů a je to čím dál a posílá hodně zpráv, že je to dobré znamení, že je to poměrně dynamický objekt třídy a měl by mít pravděpodobně stavový diagram pro něj. Také pro agregací, kde máte celý jeho částí, dělám stavový diagram pro každou kameniva celku. Dělám to hlavně proto, že agregát celek je často zodpovědný za řízení zpráv, díky němuž je dynamická.
diagramy komponent
Samozřejmě žádný systém může být postaven bez ohledu na fyzický svět. To je, kde diagramy komponent dovnitř. Jsou používány pro ilustraci organizace a závislostí mezi softwarovými komponentami, včetně zdrojového kódu komponent, doba chodu komponentů, nebo spustitelný komponenty. Komponenty jsou ukazuje jako velký obdélník s dvěma menšími obdélníky na straně, jak je vidět na obrázku 15.
Obrázek 15: Komponenty
Tyto kulaté věci představují rozhraní (často nazýván lízátko tvar). V tomto případě se ukazuje, že Register.exe je závislá na rozhraní k jak Course.dll a People.dll. To znamená, že pokud se změní tato rozhraní, bude to mít dopad na Register.exe. Vím, že je to pravidlo, když stavíte rozhraní, která říká, že “”ty nesmí měnit rozhraní.”” Ale nemá někdo skutečně pracovat tam, kde je vynuceno, že toto pravidlo? Toto schéma nám říká, co rozhraní jsou používány co jsou spustitelné běží na svých procesorů.
Obrázek 16: Nasazení schéma
rozšíření UML
Poslední věc, kterou chci zdůraznit, o UML je, že může být prodloužena. Když postavený UML, že velmi moudře uvědomil, že neexistuje žádný způsob, jak by mohli vytvořit notaci, která by mohla potěšit všechny lidi po celou dobu. Tak nám dali koncept stereotypu. Stereotyp říká, že mohu vzít si základní modelování prvek a dát mu větší význam. Stereotypy mohou být použity ke klasifikaci a rozšíření asociací, dědičnost vztahy, třídy, a komponenty.
Obrázek 17: Web stereotyp příklad
Obrázek 17 znázorňuje schéma našich webových stereotypů. Webová stránka má typicky věci, které běží na serveru a věci, které běží na straně klienta. Pokud stavíte webovým aplikacím, co se běží na straně klienta a server má zásadní význam. Takže máme celou řadu stereotypů, které ukazují, že. Malé kola představují věci, které běží na serveru. Takže při pouhém pohledu na tomto jediném schématu mohu vidět, co běží na serveru, co běží na straně klienta, a to, co obchodní objekty budou muset vypořádat s.

“——————————————————————————————————————————————————

Support translation: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”The UML is the standard language for specifying, visualizing, constructing, and documenting all the artifacts of a software system.””
Activity Diagrams
The logical place to start walking through some of the UML diagrams is by looking at activity diagrams.
Figure 2: Activity diagram
Activity diagrams show the flow of control. As illustrated in Figure 2, you can see activities represented as rounded rectangles. Activities are typically action states — states that transition automatically to the next state after the action is complete. The filled in circle represents the start of the activity diagram — where the flow of control starts. Transitions shown as arrows show how you move from activity to activity. Synchronization bars show how activities happen in parallel. I can guard a transition that says “”I want you to go to this activity only if this condition is true,”” and I can show you where it stops. Now if you’re a certain age, you’ll probably look at this activity diagram and think, “”hmm … that looks like a flow chart.”” And that’s exactly what it is, except I’m not doing it down at the programming level. Typically, I use an activity diagram fairly early on in my analysis and design process to show business workflow. I’ll also use them to show where each of my use cases might be in an activity to illustrate what use case has to happen. I also use activity diagrams to show how things flow between my use cases.
But one of the great things about the UML is its versatility. So while I use activity diagrams at the beginning of the lifecycle, others can use them in a different phase entirely. I’ve seen people use activity diagrams down at the design level where they had a very complicated set of algorithms for a particular class. And many people use them to show the flow between the methods of a class.
the system. Actors are represented as stick figures.
Figure 4: Actors
The example that I worked up for this introduction to UML is a little model of a course registration system. So in this instance, the first thing I would do when starting my analysis process is to ask, “”who is going to interact with this system?””
For the course registration model, I have a registrar, a professor, and a student. I also have an external billing system. This billing system also qualifies as an actor. (See, an actor doesn’t have to be a person — it’s anything that interacts with the system but is outside of the system.)
A use case is a sequence of related transactions performed by an actor in the system in a dialog. Or, to put it in English, a use case is a chunk of functionality. And here’s the key: it is not a software module — it is something that provides value to the actor.
Use cases are shown as ovals, and the easiest way to find them is to look at each of your actors and ask yourself why do they want to use the system. In my case, my registrar is going to maintain the curriculum, my professor is going to request a roster, my student maintains the schedule, and my billing system receives the billing information. So I create my use cases by looking at it from the customer point of view and asking, “”so, mister system actor, why do you want to use the system? What value does this system provide to you?””
The next step, once you’ve identified how your actors will be interacting with the system, is do document your use cases. Each use case needs to be documented with the flow of events, and this is done from the actor’s point of view. It should detail what the system must provide to the actor when the use case is executed. Typically it will show things like how the use case starts and finishes. What things does that use case have to do? You’ll have the normal flow of events (what I call the “”happy days”” scenario), where everything works. Then you’ll get the abnormal flow of events, the “”rainy day”” scenario. What happens when the system doesn’t work? I’ve found by documenting my flow of events that I always start with the happy days scenario.
Take as an example, walking up to an automated teller machine. You walk up to the ATM and insert your card. It asks for your PIN number. You enter it, and you are asked what you would like to do. You say “”I want some money.”” It asks where the money should be taken from. You tell it to take it from your checking account. It asks how much. You say $100.00. Then magic happens … it gives you $100.00. Then it asks if you want another transaction. You say no. It gives you your card back, gives you a receipt, and the transaction is over. That’s the happy day scenario.
Second scenario. You go up to the ATM, insert your card, and enter your PIN. The ATM tells you it’s the wrong PIN. You enter your number again. Again you are told that the PIN is incorrect. You In my course registration example, for instance, you can see that there are a lot of “”if X then Y”” workflows. That’s where you want your customer to help you out. Getting agreement early means your customer understands these scenarios and says “”yes, this is what we want.”” Use cases are a great way to ensure that what you’re building is really what the customer wants, because they show the actors, the use cases, and the relationships between them.
Figure 5: Use case diagram
So we have a great diagram that graphically shows me what? The answer is simple — it is a great diagram that shows a good overview of the system. It shows what is outside the system (actors) and the functionality that the system must provide (use cases). If there is a legacy system you need to take into consideration, here’s where you deal with it. Forcing me to work with these types of interfaces very early in the project means that I won’t be faced with the prospect of waiting until coding starts to figure out how I’m going to talk to that black box that I can’t change.
One more thing you should know about use cases is the use case realization. This is the “”how”” of the use case. It’s usually a bucket that contains three different types of diagrams: sequence diagrams, collaboration diagrams, and a class diagram that we call a view of participating classes. Use case realizations are basically a way of grouping together a number of artifacts relating to the design of a use case.
Sequence Diagrams
Sequence diagrams show object interactions arranged in a time sequence. I can use the flow of events to determine what objects and interactions I will need to accomplish the functionality specified by the flow of events.
Figure 6: Sequence diagram
Figure 6 shows how a student successfully gets added to a course. The student (let’s call him Joe) fills in some information and submits the form. The form then talks to the manager and says “”add Joe to Math 101.”” The manager tells Math 101 that it has to add a student. Math 101 says to Section 1 “”are you open?”” In this case, Section 1 replies that they are open, so Math 101 tells section 1 to add this student. Again, sequence diagrams are great tools in the beginning because they show you and your customer step-by-step what has to happen.
From an analysis point of view, I’ve found over the years that sequence diagrams are very powerful in helping me drive requirements; especially requirements that are hard to find. User interface requirements, for instance, are notorious because you always seem to get requirements that are just not testable. A common UI requirement like this is “”this system shall be user-friendly.”” How many of you have met a friendly computer? One of the benefits of these types of diagrams is that every line coming from an actor that represents a person, tells you that something in your UI has to provide a capability needed by that person. In other words, you can use sequence diagrams to drive out testable user interface requirements.
Sequence diagrams are, therefore, good for showing what’s going on, for driving out requirements, and for working with customers. That usually leads to the question, though, of how many do you need to create? My answer is, “”until you do enough.”” You’re going to find out when you do sequence diagrams that you reach a point where you’re not finding any new objects, not finding any new messages, and that you’re typing the same thing over and over. In the example of Joe joining Math 101, we learn that the process would be the same if Joe wanted to join History 101. So, rule of thumb, do a sequence diagram for every basic flow of every use case. Do a sequence diagram for high-level, risky scenarios, and that should be enough. That’s how many sequence diagrams I do.
to remember here, is that a collaboration diagram is just a different view of a scenario and you can go back and forth between sequence diagrams and collaboration diagrams to get the view that best illustrates your point.
Occasionally, you might hear the phrase “”interaction diagrams.”” Sometimes people will collectively refer to a collaboration diagram and a sequence diagram as an interaction diagram.
Class Diagrams
A class is a collection of objects with common structure, common behavior, common relationships, and common semantics. You find them by examining the objects in sequence and collaboration diagrams, and they are represented in the UML as a rectangle with three compartments.
Figure 8: Classes
The first compartment shows the class name, the second shows its structure (attributes), and the third shows its behavior (operations). These compartments can be suppressed, however, so that you can see just the name, just the name and the attributes, or all three. One thing you should also know is that it’s important, when naming classes, to use the vocabulary of the domain and pick a standard. For this instance, my classes are all singular nouns that begin with a capital letter. You may choose to do it differently, and that doesn’t matter. What does matter is that before your project you pick a standard and stick with it so that everything is consistent across the project.
Class Diagrams show you the static nature of your system. These diagrams show the existence of classes and their relationships in the logical view of a system. You will have many class diagrams in a model.
The UML modeling elements found in class diagrams include:
Classes and their structure and behavior.
Association, aggregation, dependency, and inheritance relationships.
Multiplicity and navigation indicators
Role names.
Take a look at Figure 9. This diagram shows operations (behavior): what an object in that class can do. I find my operations by looking at my interactions diagrams.
Figure 9: Operations
Here I’m saying that I need to be able to ask the registration manager to add a student to Math
101. That’s going to translate into an operation called “”addCourse.””
The structure of a class is represented by its attributes. So how do I find my attributes? By talking to domain experts. By looking at my requirements. In my example, I learn that each course offering has a number, a location, and a time. This translates out to three attributes.
classes. (Represented in the UML as a line connecting the related classes with a diamond next to the class representing the whole.)
• Dependency — a weaker form showing the relationship between a client and a supplier where the client does not have semantic knowledge of the supplier. A dependency says “”I need your services, but I don’t know that you exist.”” (Represented in the UML as a dashed line pointing from the client to the supplier.)
To find relationships, once again, I go back to my sequence diagram. If two objects need to “”talk””, there must be a means to do so (i.e., a relationship between their classes).
I typically start out and make everything an association. As I’m doing more analysis, I might find I have an aggregation because I’m going to have to take care of a parent-child relationship. When I get into the design phase, I find out that I might not need an association because somebody else is going to pass that object into one of my methods — so I make it a dependency.
Figure 11: Relationships
In Figure 11 you see these relationships. As association says the Professor can talk to the Course Offering, and the Course Offering can talk to the Professor. Messages can be initiated and data can flow from any direction. Aggregation is shown by having the diamond toward the whole — in this case a Course is made up of Course Offerings. The reason for this aggregation would be to tell my developers that if they get rid of this Course, they’ll probably have to do something special with the Course Offerings. Dependencies are shown as a dashed line. It’s saying that the registration manager depends upon the Schedule Algorithm to do something. The Schedule Algorithm is either a parameter to one of the methods or is declared locally by one of the Methods of the Registration Manager.
Multiplicity and Navigation
Multiplicity defines how many objects participate in a relationship. It is the number of instances of one class related to one instance of the other class. For each association and aggregation, there are two multiplicity decisions to make: one for each end of the relationship. Multiplicity is represented as a number and a * is used to represent a multiplicity of many.
Figure 12: Multiplicity and navigation
One Professor Object is related to zero-to-four Course Offering Objects. One Course Offering Object is related to exactly one Professor Object. I use this to look at and ensure that this handles my requirements. Can I be a Course Offering and be team-taught by a bunch of professors? No, because this says I can only have one professor. Can I be a professor and be on sabbatical? Yes, because this says I have a zero as possible course load. I use multiplicity quite often to help me start capturing and implementing my business rules. If you have, for example, a business rule that says you must have at least 3 students and no more than 10 for a course to be offered in a semester, these multiplicity numbers tell me I’ve incorporated that business rule into this plan.
Navigation is shown by an arrow, and although associations and aggregations are bi-directional by default, it is often desirable to restrict navigation to one direction. When navigation is restricted, an arrowhead is added to indicate the navigational direction. One of the things I do during the analysis and design phases is look at what I want to be uni-directional. By putting the arrow into this diagram, I say that the Registration Manager can send a message to the Course, because it knows the Course exists. But the Course has no idea that the Registration Manager exists, so the Course cannot initiate a message. Now data can flow between them; for instance the Registration Manager can ask the Course if it’s open and the Course can say that it is. But only the Registration Manager can start that conversation.
Obviously the goal here is to get as many arrows as you can by the time you’ve finished designing, because it’s a much easier system to maintain Inheritance is shown with a triangle. This shows that the Professor is a Registration User, as is the Student. Now, a word of warning. Inheritance is useful, however, the goal is not to use as much inheritance as your system will allow. I’ve seen some really brutal systems where they had inheritance 17-levels deep. If they changed one thing, it became a disaster. So the rule of thumb is to use inheritance only when you truly do have an inheritance situation.
State Transition Diagrams
A state transition diagram shows the life history of a given class. It shows the events that cause a transition from one state to another, and the actions that result from a state change.
Figure 14: State transition diagram
I use state transition diagrams for object classes that typically have a lot of dynamic behavior. The button is on … the button is off; I’m not going to do a state chart for it. But object classes that have a lot of dynamic behavior, I’m probably going to have to look into the states of the objects.
I start by showing a state, which is a rounded triangle. I can have start states, and I can have stop states, which are shown as bulls eyes. I can also have transitions between states, or guard transitions (things that happen when only when a condition is true), or things that happen when I’m inside the state. I look at this diagram and see the state transition diagram for a course offering. It starts in the initialization state, and I stay in that state until I get an “”add student”” message. When I get that message, I set my count of student to zero and I transition to the Open state. You’ll see in Figure 14 that I have an entry, and the reason why it’s there is that I have two ways of getting into that state. It says that no matter how you come into the state, I want you to register the student. When I exit that state, the count changes to keep track of the number of students in the course. I can keep adding students until I get to 10, and then I go to the Close state. Once the course is finalized, I transition to the stop state. No matter where I am then, if I get the Cancel Event transition, I notify my students and then transition to the stop state.
For object classes that have a lot of dynamic behavior, it’s well worth it to do a state diagram to get a handle on everything that has to happen. Ask yourself what happens when I get a message? What do I do when I get the message? What messages to I have to send? A lot of those messages become operations of the object class, as in this example where add a student is an operation. A lot of these actions, like setting the count, incrementing the count, checking the count, these all become private operations of that particular object class and a state diagram is where I see that.
How do you know if you have a dynamic object class? Once again, go back to the sequence diagrams. If you have an object class that’s on a lot of sequence diagrams and it’s getting and sending a lot of messages, that’s a good indication it’s a fairly dynamic object class and it should probably have a state chart for it. Also for aggregations, where you have the whole of its parts, I do a state chart for every aggregate whole. I do this mostly because that aggregate whole is often responsible for managing the messaging, which makes it dynamic.
Component diagrams
Of course no system can be built without taking into account the physical world. That’s where component diagrams come in. They are used to illustrate the organizations and dependencies among software components, including source code components, run time components, or an executable component. Components are shows as a large rectangle with two smaller rectangles on the side, as seen in Figure 15.
Figure 15: Components
Those round things represent interfaces (often called lollipop notation). In this case, they show that the Register.exe is dependent upon interfaces to both the Course.dll and the People.dll. That means if these interfaces change, it will impact the Register.exe. I know that there’s this rule when you’re building interfaces that says “”thou shall not change the interface.”” But does anybody actually work where that rule is enforced? This diagram tells us what interfaces are used by what executables are running on my processors.
Figure 16: Deployment diagram
Extending UML
The last thing I want to stress about the UML is that it can be extended. When they built the UML, they very wisely realized that there was no way they could create a notation that could please all of the people all of the time. So they gave us the concept of a stereotype. A stereotype says I can take a basic modeling element and give it more meaning. Stereotypes may be used to classify and extend associations, inheritance relationships, classes, and components.
Figure 17: Web stereotype example
Figure 17 shows the diagram of our Web stereotypes. A Web page typically has stuff that runs on the server and stuff that runs on the client. If you’re building Web-based applications, what’s running on the client and the server is of vital importance. So we have a whole set of stereotypes that show that. The little wheels represent things that run on the server. So just by looking at this one diagram I can see what runs on the server, what runs on the client, and what business objects they have to deal with.

“——————————————————————————————————————————————————

Subteno traduko: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”La UML estas la norma lingvo por preciziganta, bildiganta, konstruante, kaj dokumentante ĉiujn artefaktojn de softvara sistemo.””
Aktivecdiagramoj
La logika loko por komenci marŝi tra iu el la UML diagramoj estas rigardante aktiveco diagramoj.
Figuro 2: Aktiveco diagramo
Aktivecdiagramoj montras la fluon de kontrolo. Kiel ilustrita en la figuro 2, vi povas vidi aktivecoj reprezentitaj kiel rondeta ortanguloj. Aktivecoj estas tipe ago ŝtatoj â € “”asertas ke transiro aŭtomate al la sekva stato post la ago estas kompleta. La plenigita en cirklo reprezentas la komencon de la aktiveco diagramo â € “”kie la fluo de kontrolo komencoj. Transiroj montrita kiel sagoj montri kiel vi movas de aktiveco al la aktiveco. Sincronización stangoj montri kiel agadoj okazos en paralela. Mi povas gardi transiro kiu diras “”mi volas ke vi iru al tiu aktiveco nur se ĉi tiu kondiĉo estas vera,”” kaj mi povas montri vin kie haltas. Nun se vi estas certa aĝo, vi probable rigardi ĉi aktiveco diagramo kaj pensi, “”hmm â € | kiu similas fluo abako.”” Kaj tio estas ĝuste kio ĝi estas, krom mi ne faris ĝin malsupren ĉe la programado nivelo. Tipe, mi uzas aktivecon diagramo sufiĉe frue en mia analizo kaj dezajno procezo montri negoco laborfluo. Mi ankaŭ uzas ilin por montri kie ĉiu mia uzo kazoj povus esti en aktiveco por ilustri kion uzo kazo devas okazi. Mi ankaŭ uzas aktiveco diagramoj montri kiel aferoj fluas inter mia uzo kazoj.
Sed unu el la grandaj aferoj pri la UML estas lia versatilidad. Do dum mi uzas aktiveco diagramoj komence de la ciklo de vivo, aliaj povas uzi ilin en malsama fazo tute. Mi vidis homojn uzi Aktivecdiagramoj antaux la dezajno nivelo kie ili havis tre komplika aro de algoritmoj por aparta klaso. Kaj multaj homoj uzas ilin por montri la fluon inter la metodoj de klaso.
la sistemo. Aktoroj estas reprezentitaj kiel bastono figuroj.
Figuro 4: Aktoroj
La ekzemplo, kiun mi laboris ĉe ĉi enkonduko al UML estas iom modelo de kurso registriĝo sistemo. Do en ĉi tiu kazo, la unua afero mi fari kiam komencante mia analizo procezo estas demandi, “”kiu tuj interagos kun ĉi tiu sistemo?””
Por la kurso registriĝo modelo, mi havas registristo, profesoro kaj studento. Mi ankaŭ havas eksterajn facturación sistemo. Ĉi facturación sistemo ankaŭ kvalifikas kiel aktoro. (Vidu, aktoro ne devas esti persono â € “”tio estas io ke interagas kun la sistemo sed estas ekster la sistemo.)
A uzo kazo estas vico de rilataj transakcioj elfarita de aktoro en la sistemo en dialogo. Aŭ, por meti ĝin en la angla, uzo kazo estas eron de funcionalidad. Kaj jen la ŝlosilo: ĝi ne estas programaro modulo â € “”estas iu kiu provizas valoron por la aktoro.
Uzo kazoj vidiĝas kiel ovaloj, kaj la plej facila maniero por trovi ilin estas rigardi ĉiun de viaj aktoroj kaj demandi vin mem kial ili volas uzi la sistemon. En mia kazo, mia registristo tuj subteni la instruplano, mia profesoro tuj peti nomliston, mia studento subtenas la horaron, kaj mia facturación sistemo ricevas la facturación informo. Do mi kreos mian uzo kazoj por rigardi ĝin de la kliento vidpunkto kaj demandante, “”do, sinjoro sistemo aktoro, kial vi volas uzi la sistemon? Kio valoro ne tiu sistemo provizos al vi?””
La sekva paŝo, iam vi identigita kiel via aktoroj estos interagante kun la sistemo, estas do dokumenti vian uzon kazoj. Ĉiu uzo kazo devas esti dokumentita per la fluo de eventoj, kaj ĉi tio faras de la aktoro vidpunkto. Ĝi devus detale kion la sistemo devas provizi al la aktoro kiam la uzo kazo estas ekzekutita. Tipe ĝi montros aĵoj kiel la uzo kazo komenciĝas kaj finiĝas. Kion signifas tiu uzo kazo devas fari? Vi havos la normala fluo de eventoj (kion mi nomas la “”feliĉaj tagoj”” scenaro), kie ĉio funkcias. Tiam vi ricevos la eksternorma fluon de okazaĵoj, la “”pluva tago”” scenaro. Kio okazas kiam la sistemo ne funkcias? Mi trovis per dokumentanta mian fluon de okazaĵoj kiuj ĉiam komencas kun la feliĉaj tagoj scenaro.
Prenu kiel ekzemplon, marŝante ĝis aŭtomata kasisto maŝino. Marŝas ĝis la ATM kaj enmeti vian karton. Petu viajn PIN nombro. Vi eniras, kaj vi demandas kion vi ŝatus fari. Vi diras “”Mi volas iom da mono.”” Ĝi demandas kie la mono devus esti prenita de. Vi diris gxin preni ĝin el via kontrolanta konton. Ĝi demandas kiom. Vi diris $ 100.00. Tiam magio okazas â € | gxi donas vin $ 100.00. Tiam demandas ĉu vi volas alian transakcio. Vi diras ne. Ĝi donas vian karton reen, donas al vi kvitancon, kaj la transakcio estas finita. Jen la feliĉa tago scenaro.
Dua scenaro. Vi iru al la kasisto, enŝovu vian karton, entajpu vian PIN. La kasisto diras vin ĝi estas la malĝusta PIN. Vi eniri vian numeron denove. Denove vi estas dirita ke la PIN estas malĝusta. Vi En kuradon registriĝo ekzemple, ekzemple, vi povas vidi ke estas multaj “”se X tiam Y”” fluoj de laboro. Tio estas kie vi volas vian kliento por helpi vin. Getting interkonsento frua signifas via kliento komprenas tiujn scenarojn kaj diras “”jes, tio estas kion ni deziras.”” Uzo kazoj estas granda vojo por certigi ke kion vi konstruado estas vere kion la kliento volas, ĉar ili montras la aktoroj, la uzo kazoj, kaj la rilatoj inter ili.
Figuro 5: Uzu kazo diagramo
Do ni havos grandan diagramo kiu grafike montras min kio? La respondo estas simpla â € “”gxi estas granda diagramo kiu montras bonan superrigardon de la sistemo. Ĝi montras kio estas ekster la sistemo (aktorojn) kaj la funcionalidad kiu la sistemo devas provizi (uzo kazoj). Se estas legaco sistemo vi devas preni en konsideron, jen kie vi trakti ĝin. Devigante min al labori kun ĉi tiuj tipoj de interfacoj frua projekto signifas ke mi ne estos alfrontita kun la perspektivo de atendas ĝis kodigo komencas elkompreni kiel mi tuj parolos kun tiu nigra skatolo kiun mi ne povas ŝanĝi .
Unu pli aferon vi devas scii pri uzo kazoj estas la uzo kazo realigo. Tio estas la “”kiel”” de la uzo kazo. Ĝi estas kutime sitelo kiu enhavas tri malsamajn tipojn de diagramoj: sekvenco diagramoj, kunlaborado diagramoj, kaj klaso diagramo kiu ni nomas viditaj de partoprenantaj klasoj. Uzo kazo komprenoj estas esence maniero de kolektante kune kelkaj artefaktoj rilatigantaj al la dezajno de uzo kazo.
Sinsekvodiagramoj
Sinsekvodiagramoj montras celon interagoj aranĝitaj en tempo sekvenco. Mi povas uzi la fluo de eventoj determini kio celoj kaj interagoj Mi devas plenumi la funkciojn specifita de la fluo de la okazaĵoj.
Figuro 6: Sekvenco diagramo
Figuro 6 montras kiel studento sukcese akiras aldonita al kurso. La studento (ni nomas lin JOE) plenigas en iu informo kaj submetas la formo. Formo tiam parolas al la manaĝero kaj diras “”aldoni Joe Matematiko 101.”” La direktisto diras Math 101 kiu devas aldoni studento. Math 101 diras al Section 1 “”estas vi malfermas?”” Tiukaze, Sekcio 1 respondoj ke ili estas malfermitaj, do Math 101 diras sekcio 1 aldoni tiun studento. Denove, sekvenco diagramoj estas grandaj iloj en la komenco ĉar ili montras vin kaj via kliento paŝo post paŝo kion devas okazi.
El analizo vidpunkto, mi trovis super la jaroj kiuj sekvenco diagramoj estas tre potenca en helpanta min veturi postuloj; Precipe postuloj kiuj estas malfacile trovi. Uzantinterfaco asignoj, ekzemple, estas konata pro vi ĉiam ŝajnas atingi postuloj kiuj estas simple ne testable. Komuna UI postulo tiel estas “”tiu sistemo estos uzantamika.”” Kiel multaj el vi renkontis amikan komputilo? Unu el la avantaĝoj de ĉi tiuj tipoj de diagramoj estas ke ĉiu linio venas de aktoro kiu reprezentas personon, diras vin ke io en via UI devas havigi kapablo bezonata de tiu persono. Alivorte, vi povas uzi sekvencon diagramoj elpeli testable uzantinterfaco postuloj.
Sekvenco diagramoj estas do bona por montri kio okazas, por forpelante postulojn, kaj por labori kun klientoj. Kiu kutime kondukas al la demando, kvankam, kiom vi bezonas por krei? Mia respondo estas, “”ĝis vi faros sufiĉe.”” Vi tuj trovos kiam vi fari sekvencon diagramoj kiuj vi atingos punkton kie vi ne trovante novajn objektojn, ne trovante novajn mesaĝojn, kaj ke vi tajpas la saman aferon denove kaj denove. En la ekzemplo de Joe aliĝado Math 101, ni lernas ke la procezo estus la sama se Joe volis aliĝi Historio 101. Do, regulo, do vico diagramo por ĉiu baza fluo de ĉiu uzo kazo. Ĉu vico diagramo por altnivela, riska scenaroj, kaj tiu devus esti sufiĉa. Tiel multaj sekvenco diagramoj mi faras.
memori tie, estas ke kunlaborado diagramo estas nur malsama vido de scenejo kaj vi povas iri tien kaj reen inter sekvenco diagramoj kaj kunlaborado diagramoj akiri la vidon ke bona ilustras vian punkton.
Foje, vi eble aŭdis la frazon “”interago diagramoj.”” Foje homoj kolektive rilatas al kunlaborado diagramo kaj vico diagramo kiel interago diagramo.
Klasdiagramoj
Klaso estas kolekto de objektoj kun komunaj strukturo, komuna konduto, komunajn interrilatojn, kaj komuna semantiko. Vi trovos ilin ekzamenante la objektoj en ordono kaj kunlaborado diagramoj, kaj estas reprezentita en la UML kiel rektangulo kun tri kupeoj.
Figuro 8: Klasoj
La unua kupeo montras la klasnomo, la dua montras lian strukturon (atributoj), kaj la tria montras lian konduton (operacioj). Tiuj kupeoj povas elstrekita, tamen, tiel ke vi povas vidi ĝuste la nomon, nur la nomo kaj la atributoj, aŭ ĉiuj tri. Unu afero vi devus ankaŭ scias estas ke ĝi estas grava, kiam enoficigante klasoj, uzi la vortotrezoron de la domajno kaj pluki normo. Por tiu okazo, miaj klasoj estas ĉiuj singularaj substantivoj kiuj komencas per majusklo. Vi povas elekti por fari ĝin malsame, kaj tio ne gravas. Kio gravas estas ke antaŭ via projekto vi elektu norman kaj bastono kun ĝi por ke ĉio estas kohera trans la projekto.
Klasdiagramoj montras vin la statika naturo de via sistemo. Tiuj diagramoj montras la ekziston de klasoj kaj iliaj interrilatoj en la logikaj vido de sistemo. Vi havos multajn klaso diagramoj en modelo.
La UML modelado elementoj trovitaj en klaso diagramoj inkludas:
Klasoj kaj ilia strukturo kaj konduto.
Asocio, agrego, dependeco, kaj heredaĵon interrilatoj.
Obleco kaj navigado indikiloj
Rolo nomoj.
Rigardu Figuro 9. Tiu diagramo montras operacioj (konduto): kia objekto en tiu klaso povas fari. Mi trovas mian operacioj rigardante mian interagoj diagramoj.
Figuro 9: Operacioj
Tie mi estas diranta ke mi bezonas por povi demandi la registriĝo direktisto aldoni studento al Math
101. Tio tuj traduki en operacio nomita “”addCourse.””
La strukturon de klaso estas reprezentita de liaj atributoj. Do kiel mi trovas mian atributoj? Parolante al regado spertuloj. Rigardante mian postuloj. En mia ekzemplo, mi lernas ke ĉiu kurso oferon havas nombron, loko kaj tempo. Tio tradukiĝas al tri atributoj.
klasoj. (Reprezentita en la UML kiel linio konektanta la rilatajn klasojn kun diamanta apud la klaso kiu reprezentas la tuto.)
â € ¢ Dependeco â € “”pli malforta formo montranta la rilato inter kliento kaj provizanto kie la kliento ne havas semantikan scion de la provizanto. A dependeco diras “”mi bezonas viajn servojn, sed mi ne scias, ke vi ekzistas.”” (Reprezentita en la UML kiel kuregis linio montrante de la kliento al la provizanto.)
Trovi rilatoj, refoje, mi reiros al mia vico diagramo. Se du objektoj necesas “”paroli””, oni devas esti rimedo por fari tion (tio, rilato inter siaj klasoj).
Mi kutime komencas eksteren kaj fari ĉiun asocion. Kiel mi faras pli analizo, mi trovas ke mi havas agregación ĉar mi tuj devos prizorgi gepatro-infana rilato. Kiam mi eniras en la dezajno fazo, mi trovas ke mi ne bezonas asocion ĉar iu alia estas preterpasonta objekto en unu el miaj metodoj â € “”do mi faras gxin dependeco.
Figuro 11: Interrilatoj
En Figuro 11 vi vidas tiujn rilatojn. Kiel asocio diras la profesoro povas paroli kun la Kurso Ofrenda, kaj la Kurso Ofrenda povas paroli al la profesoro. Mesaĝoj povas esti komencita kaj datumoj povas flui el iu direkto. Agrego estas montrita havante la diamanton al la tuta â € “”en tiu kazo Kurso konsistas el Kurso Proponoj. La kialo por tiu agregación estus diri mian programistoj kiuj se ili seniĝi de tiu Kurso, ili verŝajne devas fari ion specialan kun la Kurso Proponoj. Dependencajoj estas montritaj kiel kuregis linio. Oni diras ke la enskribo manaĝero dependas la Horaro Algoritmo fari ion. La Horaro Algoritmo estas aŭ parametro al unu el la metodoj aŭ estas deklarita loke fare de unu el la metodoj de la Aliĝo Manager.
Obleco kaj Navigado
Obleco difinas kiom da objektoj partopreni en rilato. Estas la nombro de kazoj de unu klaso rilataj al petskribo de la alia klaso. Por ĉiu asocio kaj agregación, estas du obleco decidoj fari: oni por ĉiu ekstrema de la rilato. Obleco estas reprezentita kiel nombro kaj * estas uzata por reprezenti obleco de multaj.
Figuro 12: Obleco kaj navigado
Unu profesoro Objekto rilatas al nulo-al-kvar Kurso Ofrenda Objektoj. Unu Kurso Offering Objekto rilatas al ekzakte unu profesoro Objekto. Mi uzas tiun rigardi kaj certigi ke tiu manipulas miaj postuloj. Mi povas esti Kurso Ofrenda kaj esti teamo-instruas faskon de instruistoj? Ne, ĉar ĉi diras Mi povas nur havi unu instruiston. Mi povas esti instruisto kaj esti sur sabbatical? Jes, ĉar tiu diras Mi havas nulo kiel ebla kurson ŝarĝo. Mi uzas obleco tre ofte helpi min komenco kaptante kaj efektivigado mia negoco reguloj. Se vi havas, ekzemple, negoco regulo kiu diras vi devas havi almenaŭ 3 studentoj kaj ne pli ol 10 por kurso esti proponita en semestro, tiuj obleco nombroj diru mi korpigita ke negoco regulo en tiu plano.
Navigado indikas sago, kaj kvankam asocioj kaj aldonitaj estas dudirekta defaŭlte, estas ofte dezirinde restrikti navigado al unu direkto. Kiam navigado restriktita, kun sagpinto aldonas indiki la navigiloj direkto. Unu el la aĵoj kiujn mi faras dum la analiza kaj desegna fazoj estas rigardi kion mi volas esti uni-unudirekta. Metante sagon en tiu diagramo, mi diras ke la Registrocentro Manager povas sendi mesaĝon al la Kurso, ĉar ĝi konas la Kurso ekzistas. Sed la Kurso havas nenian ideon ke la Registrocentro Manager ekzistas, do la Kurso ne povas komenci mesaĝon. Nun datumoj povas flui inter ili; ekzemple la Aliĝo Manager povas demandi la Kurso se ĝi estas malfermita kaj la Kurso povas diri ke ĝi estas. Sed nur la Aliĝo Manager povas komenci tiun konversacion.
Evidente la celo tie estas akiri kiel multaj sagoj, kiel vi povas de la tempo vi finis desegni, ĉar ĝi estas multe pli facila sistemo por subteni Heredaĵo estas montrita per triangulo. Tio montras ke la Profesoro estas Aliĝilo Uzanto, kiel estas la Studento. Nun, vorto de averto. Posedaĵo estas utila, tamen, la celo ne estas uzi tiel heredaĵo kiel via sistemo permesos. Mi vidis iun vere brutala sistemoj kie havis heredon 17-niveloj profunda. Se ili ŝanĝis unu afero, ĝi igis katastrofon. Do la regulo de thumb estas uzi heredaĵo nur kiam vi vere ja havas heredajxon situacion.
Ŝtata Transiro Diagramoj
Stato transiro diagramo montras la vivhistorio de donita klaso. Ĝi montras la okazaĵojn kiuj kaŭzas transiron de unu stato al alia, kaj la agoj rezultantaj el ŝtataj ŝanĝo.
Figuro 14: Ŝtata transiro diagramo
Mi uzas stato transiro diagramoj por objekto klasoj kiuj tipe havas multajn dinamika konduto. La butono estas sur € | la butono estas ekstere; Mi ne intencas fari stato diagramo por ĝi. Sed objekto klasoj kiuj havas multajn dinamika konduto, mi probable tuj devos rigardi en la statoj de la objektoj.
Mi komencu per montranta staton, kiu estas rondigita triangulo. Mi havas komencon ŝtatoj, kaj mi povas havi halto ŝtatoj, kiuj estas montritaj kiel fortaj okuloj. Mi povas ankaŭ havi transiroj inter ŝtatoj, aŭ gardisto transiroj (kiuj okazas kiam nur kiam kondiĉo estas vera), aŭ aĵoj kiuj okazas kiam mi estas ene de la stato. Mi rigardas tiun diagramon kaj vidi la staton transiro diagramo por kurso oferon. Ĝi komenciĝas en la inicialización stato, kaj mi restas en tiu stato ĝis mi akiras “”aldoni studento”” mesaĝo. Kiam mi ricevas tiun mesaĝon, mi almetis mian grafo de studento al nulo kaj mi transiron al la Open stato. Vi vidos en Figuro 14 ke mi havas eniron, kaj la kialo kial ĝi estas tie estas ke mi havas du manierojn de akiranta en tiu stato. Ĝi diras ke kiel ajn vi eniros en la stato, mi volas ke vi enskribas la studento. Kiam mi eliras tiu stato, la grafo ŝanĝoj konservi trako de la nombro de lernantoj en la kurso. Mi povas teni aldonante studentoj ĝis mi alvenas al 10, kaj mi foriras al la Fermi stato. Iam la kurso estas finita, mi transiron al la halto stato. Negrave kie mi estas tiam, se mi ricevas la Nuligi Eventon transiro, mi sciigos mian studentoj kaj tiam transiro al la halto stato.
Por objekto klasoj kiuj havas multajn dinamika konduto, ĝi estas bone valora ĝi fari stato diagramo akiri anson sur ĉiu kio devas okazi. Demandu vin kio okazas kiam mi ricevas mesaĝon? Kion fari kiam mi ricevas la mesaĝon? Kio mesaĝojn al mi por sendi? Multaj el tiuj mesaĝojn iĝi operacioj de la objekto klaso, kiel en ĉi tiu ekzemplo kie aldonu studento estas operacio. Multaj de ĉi tiuj agoj, kiel opcio la grafo, pliigante la grafo, kontrolanta la grafo, tiuj ĉiuj fariĝis privata operacioj de tiu aparta objekto klaso kaj ŝtato diagramo estas kie mi vidas tion.
Kiel vi scias se vi havas dinamikan objekton klaso? Refoje, reiru al la sekvenco diagramoj. Se vi havas objekton klaso jen sur tereno de sekvenco diagramoj kaj ĝi Fariĝas kaj sendas multajn mesaĝojn, tio estas bona indiko estas sufiĉe dinamika objekto klaso kaj ĝi supozeble havas staton diagramo por ĝi. Ankaŭ por agregaciones, kie vi havas la tuta de liaj partoj, mi faras ŝtatan diagramo por ĉiu aldonita tuto. Mi faras ĉi plejparte ĉar tiu entuta tuta estas ofte respondeca administri la mesaĝoj, kiuj faras dinamikan.
komponanto diagramoj
Kompreneble neniu sistemo povas esti konstruita sen konsiderante la fizika mondo. Tio estas kie komponanto diagramoj enveni. Ili estas uzitaj por ilustri la organizoj kaj dependencajoj inter programaro komponantoj, inkluzive fontkodo komponantoj, kuri tempo komponantojn, aŭ plenumeblan komponanto. Komponantoj estas programoj kiel grandan rektangulon kun du malgrandaj rektangulojn sur la flanko, kiel vidite en figuro 15.
Figuro 15: Eroj
Tiuj rondaj aferoj reprezenti interfacojn (ofte nomata lollipop notacio). En tiu kazo, ili montras ke la Register.exe dependas sur interfacoj al ambaŭ la Course.dll kaj la People.dll. Tio signifas se tiuj interfacoj ŝanĝi, ĝi efikos la Register.exe. Mi scias, ke ekzistas tiu regulo kiam vi konstruado interfacoj kiu diras “”vi ne ŝanĝi la interfacon.”” Sed ĉu iu vere funkcias, kie tiu regulo estas deviga? Tiu diagramo Diras nin kio interfacoj estas uzitaj de kio ejecutables kuras sur mia procesoroj.
Figuro 16: Deplojo diagramo
etendante UML
La lasta afero mi deziras emfazi pri la UML estas ke ĝi povas esti etendita. Kiam oni konstruis la UML, ili tre saĝe rimarkis ke ekzistis neniu maniero ili povis krei notacio kiu povus kontentigi ĉiujn la homoj ĉiuj la tempo. Tial oni donis al ni la koncepton de stereotipo. A stereotipo diras mi povas preni bazan modeligado elemento kaj donu pli signifon. Stereotipoj uzebla klasifiki kaj etendi asocioj, heredaĵo rilatoj, klasoj kaj komponantoj.
Figuro 17: TTT stereotipo ekzemplo
Figuro 17 montras la skemon de nia TTT stereotipoj. Al Retpaĝaj tipe havas materialon kiu kuras sur la servilo kaj aĵoj kiuj kuras sur la kliento. Se vi konstruado TTT-bazita aplikoj, kio estas kurante sur la kliento kaj la servilo estas de esenca graveco. Do ni havas tutan aron de stereotipoj kiuj montras tion. La etaj radoj reprezentas aferojn kiuj kuras sur la servilo. Tiel nur rigardas ĉi tiu diagramo mi povas vidi kio kuras sur la servilo, kio funkcias en la kliento, kaj kion negoco objektojn ili devas trakti.

“——————————————————————————————————————————————————

Tõlkimise toetamise: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”The UML on kirjakeele täpsustades, visualiseerimise, ehitamise ja dokumenteerimine esemeid tarkvarasüsteemi.””
Tegevusskeemid
Loogiline koht alustamiseks jalgsi läbi mõned UML diagrammid on vaadates Tegevusskeemid.
Joonis 2: Tegevusskeem
Tegevusskeemid näitavad voolu kontrolli. Nagu joonisel 2, näed tegevuse esindatud ümardatud ristkülikuid. Tegevused on tavaliselt toime Ühendriigid ā € “”märgitakse, et üleminek automaatselt järgmisele riigi pärast tegevuse lõpetamist. Täidetud ring näitab ürituse algust diagramm ā € “”, kus voolu juhtimine algab. Transitions näidatud nooltega näidata, kuidas liikuda ühe tegevuse. Sünkroniseerimine baarid näidata, kuidas tegevus toimub paralleelselt. Ma ei valvata üleminek, mis ütleb: “”Ma tahan, et sa läheksid seda tegevust ainult siis, kui see tingimus on tõene,”” ja ma näitan teile, kus see peatub. Nüüd, kui sa oled teatud vanuses, siis ilmselt vaadata seda tegevust diagramm ja mõelda: “”hmm â € |, mis näeb välja nagu tehnoloogiline skeem.”” Ja see on täpselt see, mis see on, välja arvatud Ma ei tee seda ette kavandamise tasandil. Tavaliselt ma kasutan tegevusskeemiga üsna varakult oma analüüsi ja projekteerimise käigus näidata ettevõtte töökorraldust. Ma ka neid kasutada, et näidata, kus iga mu kasutamiseks juhtudel võib olla tegevus, et illustreerida, mida kasutada juhul peab juhtuma. Ka mina kasutan Tegevusskeemid näidata, kuidas asjad voolu vahel mu kasutamiseks juhtudel.
Aga üks suuri asju UML on tema mitmekülgsus. Niisiis, kui ma kasutan Tegevusskeemid alguses elutsükli, teised võivad neid kasutada erinevates faasides täielikult. Olen näinud inimesed kasutavad Tegevusskeemid maha disaini tasemele, kus nad olid väga keeruline kogum algoritme konkreetse klassi. Ja paljud inimesed kasutavad neid näidata voolu vahel meetodites klassiks.
süsteem. Näitlejad on esindatud kriipsujukud.
Joonis 4: Näitlejad
Näide, et ma töötasin kuni selle sissejuhatuses UML on natuke mudel muidugi registreerimise süsteemi. Nii antud juhul esimene asi, mida ma teeksin, kui algab minu analüüsi käigus on küsida, “”kes läheb suhelda selles süsteemis?””
Sest muidugi registreerimise mudel, mul on registripidaja, professor, ja üliõpilane. Mul on ka välise arveldussüsteemi. See arveldussüsteemi ka kvalifitseerub näitleja. (Vt näitleja ei pea olema inimene ā € “”see on midagi, mis suhtleb süsteemiga, vaid on väljaspool süsteemi.)
Kasutamise puhul on jada omavahel seotud tehingud, mida näitleja süsteemi dialoogi. Või pane see inglise keeles, kasutamise puhul on tüki funktsionaalsust. Ja siin on võti: see ei ole tarkvara moodul â € “”see on midagi, mis pakub lisaväärtust näitleja.
Kasuta juhtudel näidatakse ovaali, ja lihtsaim viis leida neid on vaadata iga oma osalejate ja küsi endalt, miks nad tahavad süsteemi kasutada. Minu puhul minu registripidaja läheb säilitada õppekava, minu professor hakkab taotlema nimekirja, minu õpilane jääb ajakava ja minu arveldussüsteemi saab arvelduse andmed. Nii et ma luua minu kasutamiseks juhtudel, vaadates seda alates kliendi seisukohast ja küsib, “”nii, mister süsteem näitleja, miks sa tahad seda süsteemi? Mis väärtus see süsteem annab teile?””
Järgmine samm, kui olete kindlaks, kuidas osalejad suhtlevad süsteemi, on do dokumenteerida kasutamise juhtumid. Iga kasutamise puhul peab olema dokumentaalselt voolu sündmusi, ning seda on tehtud alates näitleja seisukohast. See peaks olema täpselt mida süsteem peab andma näitlejale kui kasutada juhul täidetakse. Tavaliselt see näitab asju nagu kuidas kasutada juhul algab ja lõpeb. Mis asjad ei et kasutada juhul tegema? Sul on normaalset voolu sündmusi (mida ma nimetan “”õnnelikud päevad”” stsenaarium), kus kõik toimib. Siis saad ebanormaalne voolu sündmuste “”mustadeks päevadeks”” stsenaarium. Mis juhtub siis, kui süsteem ei tööta? Olen märganud, dokumenteerides oma voolu sündmusi, mis ma alati alustada õnnelikud päevad stsenaariumi.
Võtke näiteks kõndides kuni rahaautomaat. Sa kõndida kuni ATM ja sisesta oma kaardi. Ta küsib PIN-koodi sisestamata. Sa sisestage see ja siis küsitakse, mida sa tahaksid teha. Sa ütled: “”Ma tahan natuke raha.”” Ta küsib, kuhu see raha tuleks võtta. Sa öelda, et see võtaks ta oma pangakonto. Ta küsib, kui palju. Sa ütled $ 100,00. Siis magic juhtub € | see annab teile $ 100,00. Siis küsib, kas soovite teise tehingu. Sa ei öelda. See annab sulle oma kaardi tagasi, annab teile kätte, ja tehing on möödas. See on õnnelik päev stsenaariumi.
Teine stsenaarium. Lähed kuni ATM sisestada oma kaardi ja PIN-koodi sisestamisel. ATM ütleb, et see on vale PIN-koodi. Sa Sisestage number uuesti. Taas te olete rääkinud, et PIN on vale. Sa Minu muidugi registreerimise näiteks näiteks näed, et seal on palju “”, kui X, siis Y”” tööprotsesse. See, kui soovite oma klientide aidata teil välja. Kuidas kokkulepe ennetähtaegselt tähendab teie klient mõistab neid stsenaariume ja ütleb: “”Jah, see on see, mida me tahame.”” Kasuta juhtudel on suurepärane võimalus tagada, et mida sa oled hoone on tõesti see, mida klient tahab, sest nad kujutavad näitlejad, kasutamise juhtudel ja nendevahelised suhted.
Joonis 5: Kasutage juhul skeem
Nii et meil on suur skeem, mis näitab graafiliselt mida? Vastus on lihtne â € “”see on suur skeem, mis näitab head ülevaadet süsteemi. See näitab, mida on väljaspool süsteemi (osalejad) ja funktsionaalsust, et süsteem peab andma (kasutamise juhtudel). Kui on olemasoleva süsteemi, mida pead arvestama, et siin on, kus sa sellega tegeleda. Sunnivad mind töötama nende liideste tüüpide väga varakult projekti tähendab, et ma ei saa ees oodata oodata, kuni kodeerimine hakkab mõtlema, kuidas ma lähen rääkima, et must kast, mida ma muuta ei saa .
Veel üks asi, mida peaks teadma kasutamise juhtudel on kasutada juhul teostus. See on “”kuidas”” kasutamise puhul. See on tavaliselt ämber, mis sisaldab kolme erinevat tüüpi diagrammid: järgnevusskeemilt, Koostööskeemid ja klassi diagrammi, mida me nimetame vaade osalevad klassid. Juhtumi arusaamad on põhimõtteliselt nii, koondades mitmeid esemeid, mis on seotud disaini kasutamise puhul.
järgnevusskeemilt
Järgnevusskeemilt näidata objekti vastasmõju paigutatud ajalises järjestuses. Ma ei kasuta voolu sündmusi millised objektid ja interaktsioonid ma vaja täita funktsionaalsust määratud voolu sündmusi.
Joonis 6: Järgnevusskeem
Joonis 6 näitab, kuidas õpilane on edukalt saab lisada muidugi. Üliõpilane (nimetame teda Joe) täidab teatud informatsiooni ja esitab vormi. Vormi siis räägib juht ja ütleb “”add Joe matemaatikale 101.”” Juht ütleb Math 101, et tal on lisada üliõpilane. Math 101 ütleb, et 1. jagu “”on avate?”” Sel juhul 1. jagu vastuseid, et nad on avatud, nii Math 101 ütleb lg 1, et lisada see tudeng. Jällegi järgnevusskeemilt on suured vahendid alguses, sest nad näitavad teile ja teie klient samm-sammult, mida peab juhtuma.
Siit analüüsi seisukohast, ma olen leidnud aastate jooksul, et järgnevusskeemilt on väga võimas, et aidata mul sõita nõuetele; eriti nõudeid, mis on raske leida. Kasutajaliides nõudeid, näiteks on tuntud, sest sa alati tundub, et saada nõudeid, mis lihtsalt ei testitavad. Ühine UI nõue, nagu see on “”see süsteem peab olema kasutajasõbralik.”” Kui paljud teist on täidetud sõbralik arvuti? Üks kasu seda tüüpi diagrammid on see, et iga rida pärit näitleja, mis tähistab isikut, ütleb, et midagi oma UI on pakkuda võime vajalik, et isik. Teisisõnu, mida saab kasutada järgnevusskeemilt sõita välja testitav kasutajaliides nõuetele.
Järgnevusskeemilt on seega hea näitab, mis toimub, sõidu läbi nõudeid ning töötada klientidega. See põhjustab tavaliselt küsimus, kuigi, kui palju sa vajad, et luua? Minu vastus on, “”kuni sa teed piisavalt.”” Sa lähed, et teada saada, kui sa järgnevusskeemilt et jõuad punkti, kus sa ei leia ühtegi uut objekti, ei leia enam uusi sõnumeid ja et sa kirjutades sama asja üle ja üle. Näites Joe liitumisel Math 101, saame teada, et protsess oleks sama, kui Joe tahtis liituda History 101. Niisiis, rusikareegel, teha jada skeem iga põhi voolu iga kasutamise puhul. Kas järgnevusskeemiga kõrgetasemeliseks, riskantne stsenaariume, ja mis peaks olema piisav. See, kui palju järgnevusskeemilt mina.
meeles pidada, siin on see, et koostööskeem on lihtsalt teistsugusele seisukohale stsenaariumi ja võid minna edasi-tagasi järgnevusskeemilt ja Koostööskeemid saada, et kõige paremini illustreerib oma punkti.
Vahel võite kuulda fraasi “”suhtlemist diagrammid.”” Mõnikord inimesed kollektiivselt viidata koostööskeem ja järgnevusskeemiga kui interaktsiooni skeem.
klassiskeemid
Klass on objektide kogum koos ühise struktuuri, levinud käitumine, ühiseid suhted ja ühised semantika. Sa leiad neid uurides objektide jada ja Koostööskeemid ja nad on esindatud UML ristkülik, millel on kolm kambrit.
Joonis 8: Klassid
Esimene sahtel näitab klassi nimi, teine näitab oma struktuuri (atribuudid), kolmas näitab oma käitumist (toimingud). Need sektsioonid võib olla alla surutud, aga nii, et näed ainult nime, vaid nimi ja atribuudid, või kõik kolm. Üks asi, mida peaks ka teadma, et see on oluline, kui nimetades klasse, kasutada sõnavara domeeni ja valida standard. Sel juhul minu klassi on kõik ainsuses nimisõnade algab suure tähega. Võite teha seda erinevalt, ja et see ei loe. Mis asi on see, et enne oma projekti valid standard ja säilitada seda nii, et kõik on järjepidevad projekti.
Klassiskeemid näitan sulle staatilise iseloomu oma süsteemi. Need skeemid näitavad olemasolu klasside ja nende suhteid loogiline vaade süsteem. Teil on palju klassiskeemid mudelis.
UML modelleerimine elemente leidub klassi diagrammid on järgmised:
Klassid ja nende struktuuri ja käitumise.
Association, koondamine, sõltuvus ja pärandi suhteid.
Paljusus ja navigatsiooni näitajad
Roll nimed.
Heitke pilk Joonis 9. See diagramm näitab tegevust (käitumist): mis objekti selles klassis saab teha. Ma leian tegevust vaadates minu koostoimeid diagrammid.
Joonis 9: Toimingud
Siin ma öelda, et mul on vaja, et oleks võimalik küsida registreerimisjuhina lisada õpilase Math
101. See läheb tõlkida operatsiooni nimega “”addCourse.””
Struktuur klassi esindab tema atribuudid. Niisiis, kuidas ma leian atribuudid? Rääkides domeeni eksperdid. Vaadates minu nõuetele. Minu Näiteks ma teada, et iga kursus on mitmeid, asukoht ja aeg. See tähendab välja kolm atribuute.
klassidesse. (Esindatud UML ühendav sirge seotud klasside teemant kõrval klassis esindavad kogu.)
ā € ¢ Sõltuvus ā € “”nõrgem vorm, mis näitab suhet kliendi ja tarnija, kus klient ei ole semantiline tarnijale teadaolevate andmete põhjal. Sõltuvust ütleb: “”Mul on vaja oma teenuseid, kuid ma ei tea, et sa olemas.”” (Esindatud UML kriipsjoon osutades kliendi tarnija.)
Et leida suhted taas, ma lähen tagasi oma jada skeem. Kui kahe objekti on vaja “”rääkida””, seal peab olema vahend seda teha (st suhet oma klassides).
Ma tavaliselt hakkavad läbi ja teeb kõike ühendus. Nagu ma teen rohkem analüüsi, ma võiks leida Mul on liitmise, sest ma lähen on hoolitseda ema-lapse suhe. Kui ma saan Kavandamisetapis ma teada, et ma ei pruugi vaja ühing, sest keegi teine läheb edasi, et objekti üks mu meetodeid ā € “”nii et ma oleks sõltuvust.
Joonis 11: Suhted
Joonisel 11 näete neid suhteid. Kuna ühing ütleb professor saab rääkida kursus ning kursus saab rääkida professor. Sõnumeid saab alustada ja andmeid võib tuleneda mis tahes suunas. Liitmine on näidanud, millel on teemant poole kogu ā € “”antud juhul muidugi koosneb muidugi pakkumisi. Selle põhjuseks koondamine oleks öelda minu arendajad, et kui nad vabaneda seda muidugi, nad ilmselt on midagi erilist, mille muidugi pakkumisi. Sõltuvus on näidatud punktiirjoonega. See on selge, et registreerimisjuhina sõltub Ajakava algoritm midagi teha. Loendit Algoritm on kas parameetri üks meetodeid või deklareeritud on lokaalselt üks Methods registreerimistunnistuse Manager.
Paljusus ja navigatsioon
Mitmesust määratleb, mitu objekti osaleda suhe. See on arvul ühte klassi, mis on seotud ühe astme teine klass. Iga ühing ja liitmise, on kaks paljusus otsuseid teha: üks iga suhte lõppu. Mitmesust esindatud numbri ja * kujutamiseks kasutatakse paljusus palju.
Joonis 12: Mitmesust ja navigatsioon
Üks professor objekt on seotud null kuni nelja kursus objektid. Üks kursus objekt on seotud täpselt üks professor objekt. Ma kasutan seda vaadata ja tagada, et see tegeleb minu nõuetele. Kas ma saan olla kursus ja olla meeskonna õpetanud kamp professorid? Ei, sest see ütleb, et ma olla ainult üks professor. Kas ma võin olla professor ja olla võetavale? Jah, sest see ütleb mul on null kui võimalik muidugi koormust. Ma kasutan paljusus üsna sageli, et mind aidata alustada hõivamiseks ja rakendamisel minu ettevõtte reegleid. Kui teil on näiteks äri reegel, mis ütleb, siis peab olema vähemalt 3 üliõpilastele ja mitte rohkem kui 10 kursuse, mida pakutakse semestris, nende rohkus numbrid mulle Olen lisada, et äri reegel sellesse plaani.
Navigation on näidatud noolega, ja kuigi ühendused ja liitmiste kahesuunalised vaikimisi on sageli soovitav piirata navigeerimise ühes suunas. Kui navigatsiooni on piiratud, nooleots on lisatud näitavad navigatsiooni suunas. Üks asi, mida ma teen ajal analüüsi ja disaini faasis on vaadata, mida ma tahan olla ühesuunalised. Asetades nool sellesse skeemi, ütlen, et registreerimine Manager saab sõnumit saata Course, sest ta teab, muidugi olemas. Aga muidugi ei tea, et registreerimine Manager olemas, nii et ei saa loomulikult algatada sõnum. Nüüd andmed liiguks nende vahel; Näiteks registreerimist Manager saab küsida muidugi, kui see on avatud ja muidugi võib öelda, et see on. Aga ainult Registreerimine Manager saab alustada, et vestlus.
Ilmselt eesmärk siin on saada nii palju nooli nagu võite selleks ajaks olete lõpetanud projekteerimine, sest see on palju lihtsam süsteem säilitada Pärilikkus on näidatud kolmnurk. See näitab, et professor on registreerimine Kasutaja, nagu on Student. Nüüd sõna hoiatus. Pärilikkus on kasulik, aga eesmärk on mitte kasutada nii palju päri- oma süsteem võimaldab. Olen näinud mõned väga jõhker, kus need olid pärandi 17-taset sügav. Kui nad muutsid üks asi, sai katastroof. Nii et rusikareegel on kasutada pärandist ainult siis, kui sa tõesti teha on pärandi olukorda.
Riigi Transition skeemid
Olekusiirde diagramm näitab elukäigu antud klassi. See näitab sündmusi, mis põhjustavad üleminek ühest olekust teise, ning meetmed, mis tulenevad riik muutus.
Joonis 14: olekudiagrammi
Ma kasutan olekusiirde diagrammid objekti klassi, mis tavaliselt on palju dünaamilist käitumist. Nupp on ā € | nupule on välja lülitatud; Ma ei kavatse seda teha riigi ülesehitus ta. Aga objekti klasse, kus on palju dünaamiline käitumine, ma ilmselt läheb uurima Ühendriigid objektid.
Hakkan näidates riik, mis on ümardatud kolmnurk. Ma ei ole algust riigid, ja ma ei pea stop riigid, mis on näidatud pullid silma. Ma võib olla ka üleminekuid riikide vahel, või valvur üleminekud (asju, mis juhtub siis, kui ainult siis, kui tingimus on tõene) või asju, mis juhtub siis, kui ma olen sees olekus. Ma vaatan seda skeemi ja vaata olekudiagrammi jaoks kursus. See algab initsialiseerimise riigile ja jään selle oleku, kuni ma saan “”lisada õpilase”” sõnum. Kui ma saan selle sõnumi, seadsin minu count õpilaste nulli ja ma üleminek avatud olekus. Näete joonisel 14, et mul on kirje, ja miks see on, et mul on kaks võimalust sattumist, et riigile. Ta ütleb, et ükskõik kui sa tuled riik, ma tahan, et sa registreerima üliõpilane. Kui ma väljuda, et riik peab arv muutusi jälgida õpilaste arv käigus. Ma ei hoida lisades õpilased kuni saan 10 ja siis ma lähen Sule riik. Kui kursus on lõpetatud, ma üleminekuni stoppi. Ükskõik, kus ma olen siis, kui ma saan Loobu Event üleminek, ma teatama oma õpilasi ja siis üleminek stopp olekus.
Sest objekti klasse, kus on palju dünaamiline käitumine, see on ka seda väärt, et teha riigi diagramm saada käepide kõike, mis on juhtunud. Küsi endalt, mis juhtub, kui ma saan teate? Mida teha, kui saan teate? Mis sõnumit Olen saata? Palju neid sõnumeid saada tegevuse objekti klassi, nagu selles näites, kus lisada üliõpilane on operatsioon. Palju neid tegevusi, nagu millega loota, mis suureneb loota, kontrollides loota, need kõik muutunud eraettevõtjate selle konkreetse objekti klassi ja riigi diagramm on koht, kus ma näen seda.
Kuidas sa tead, kui sul on dünaamiline objekti klassi? Taas tagasi minna järgnevusskeemilt. Kui teil on objekti klassi, mis on sees palju järgnevusskeemilt ja see muutub ja saates palju sõnumeid, mis on hea märk, et see on üsna dünaamiline objekti klassi ja see tuleb tõenäoliselt riigi ülesehitus ta. Ka kogumid, kus pead kogu selle osade, mina riigi ülesehitus iga kokku terviku. Teen seda peamiselt seetõttu, et kokku kogu sageli haldamise eest vastutab sõnumid, mis muudab dünaamiline.
Komponentskeemid
Muidugi ei ole süsteemi saab ehitada, arvesse võtmata füüsilises maailmas. See, kui Komponentskeemid tulla. Neid kasutatakse illustreerivad organisatsioonide ja sõltuvusi tarkvara komponente, sealhulgas lähtekoodi komponendid, jooksuga komponente või käivitatava komponendi. Komponendid on kujutatud kui suur täisnurkne kaks väiksemat ristkülikud küljel, nagu näha joonisel 15.
Joonis 15: Komponendid
Need ümmargused asju esindavad liidesed (sageli nimetatakse pulgakomm märkus). Sel juhul nad näitavad, et Register.exe sõltub liidesed nii Course.dll ja People.dll. See tähendab, et kui need liidesed muuta, see mõjutab Register.exe. Ma tean, et seal on see reegel, kui olete hoone liidesed, mis ütleb: “”Sa ei tohi muuta kasutajaliidese.”” Aga kas keegi tegelikult töötavad, kus see reegel täitmisele? See diagramm näitab meile, mida liidesed kasutavad mida täitmisfailid töötab minu protsessorid.
Joonis 16: evitusskeem
laiendamine UML
Viimane asi, mida ma tahan rõhutada, umbes UML on, et seda saab pikendada. Kui nad ehitasid UML nad väga targalt aru, et ei ole nii, nagu nad võiksid luua märke, mis võiks palun kõik inimesed kogu aeg. Nii nad andsid meile mõiste stereotüüp. Stereotüüppaar ütleb, et ma ei võta põhi modelleerimine element ja seda enam tähendust. Stereotüübid võib kasutada klassifitseerimiseks ja laiendada ühendusi, pärimise suhted klasside ja komponendid.
Joonis 17: Web stereotüüp näiteks
Joonisel 17 diagramm meie Web stereotüübid. Veebileht tavaliselt on asjad, mis töötab serveris ja asju, mis töötab kliendiga. Kui olete hoone veebipõhiseid rakendusi, mida on töötab kliendi ja serveri on elulise tähtsusega. Nii et meil on terve rida stereotüübid, mis näitavad, et. Väike rattad esindavad asju, mis töötavad serveris. Nii lihtsalt vaadates seda ühel skeemil ma näen, mida jookseb serveris, mida töötab kliendi ja mis äri objektide nad peavad tegelema.

“——————————————————————————————————————————————————

Support translation: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”Ang UML ay ang karaniwang wika para sa pagtukoy, visualizing, paggawa, at documenting ang lahat ng mga artifacts ng isang sistema ng software.””
diagram Activity
Ang lohikal na lugar upang magsimula sa paglalakad sa pamamagitan ng ilan sa mga UML diagram ay sa pamamagitan ng pagtingin sa diagram aktibidad.
Figure 2: Activity diagram
Activity diagram ipakita ang daloy ng control. Gaya ng makikita sa Figure 2, maaari mong makita ang mga gawain kinakatawan bilang bilugan parihaba. Gawain ay karaniwang aksyon states â € “”ay nagsasaad na transition awtomatikong sa susunod na estado pagkatapos ng aksyon ay kumpleto na. Ang napunan bilog ay kumakatawan sa simula ng diagram aktibidad â € “”kung saan ang daloy ng control pagsisimula. Transitions ipinapakita bilang mga arrow ay nagpapakita kung paano mo ilipat mula sa aktibidad sa aktibidad. Synchronization bar ay nagpapakita kung paano mga aktibidad mangyari sa parallel. Maaari ko bang bantayan ang isang transition na nagsasabing “”gusto ko sa iyo upang pumunta sa mga aktibidad na ito lamang kung ang kundisyong ito ay totoo,”” at maaari kong ipakita sa iyo kung saan ito hihinto. Ngayon kung ikaw ay isang tiyak na edad, ikaw ay malamang na tumingin sa ito diagram aktibidad at sa tingin, “”hmm â € |. Na ganito ang hitsura ng isang tsart daloy”” At iyon mismo kung ano ito ay, maliban sa hindi ako ng paggawa ito pababa sa antas ng programming. Kadalasan, gamitin ko ang isang aktibidad diagram medyo maaga sa aking pagtatasa at disenyo proseso upang ipakita negosyo workflow. Kukunin ko ring gamitin ang mga ito upang ipakita kung saan bawat isa sa aking mga kaso na paggamit ay maaaring maging sa isang aktibidad upang ilarawan kung ano ang gamitin kaso ay may mangyari. Ako din gamitin ang diagram aktibidad upang ipakita kung paano mga bagay-bagay dumaloy sa pagitan ng aking mga kaso gamitin.
Ngunit isa sa mga dakilang bagay tungkol sa mga UML ay ang kanyang kagalingan sa maraming bagay. Kaya habang gamit ko diagram aktibidad sa simula ng ang lifecycle, ang iba ay maaaring gamitin ang mga ito sa isang iba’t ibang phase ganap. Nakita ko na ginagamit ng mga tao na aktibidad diagram hati sa antas ng disenyo na kung saan sila ay nagkaroon ng isang napaka-komplikadong hanay ng mga algorithm para sa isang partikular na klase. At maraming mga tao gamitin ang mga ito upang ipakita ang daloy sa pagitan ng mga paraan ng isang klase.
ang sistema. Aktor ay kinakatawan bilang stick figure.
Figure 4: Mga Aktor
Ang halimbawa na ako ay nagtrabaho up para sa pagpapakilala sa UML ay isang maliit na modelo ng isang sistema course registration. Kaya sa halimbawang ito, ang unang bagay na gusto kong gawin kapag ang simula ng aking pag-aaral proseso ay upang magtanong, “”kung sino ang pagpunta upang makipag-ugnay sa system na ito?””
Para sa mga modelo registration course, mayroon akong isang registrar, isang propesor, at isang mag-aaral. Din ako ay may isang panlabas na sistema ng pagsingil. Ito billing system din ay kuwalipikado bilang isang artista. (Tingnan, isang aktor ay hindi kailangang maging isang tao â € “”ito ay anumang bagay na nakikipag-ugnayan sa sistema ngunit nasa labas ng sistema.)
A gamitin ang kaso ay isang pagkakasunod-sunod ng mga kaugnay na mga transaksyon ginanap sa pamamagitan ng isang aktor sa sistema sa isang dialog. O, upang ilagay ito sa Ingles, isang gamitin kaso ay isang tipak ng pag-andar. At narito ang key: ito ay hindi isang software module â € “”ito ay isang bagay na nagbibigay halaga sa mga artista.
Gamitin ang mga kaso ay ipinapakita bilang mga ovals, at ang pinakamadaling paraan upang mahanap ang mga ito ay upang tumingin sa bawat isa sa iyong mga aktor at tanungin ang inyong sarili kung bakit nais nilang gamitin ang sistema. Sa aking kaso, ang aking registrar ay pagpunta upang mapanatili ang kurikulum, ang aking propesor ay pagpunta upang humiling ng isang roster, aking mag-aaral nagpapanatili ng iskedyul, at ang aking billing system na natatanggap ang impormasyon sa pagsingil. Kaya ako gumawa ng aking mga kaso na paggamit sa pamamagitan ng pagtingin sa ito mula sa mga customer na punto ng view at nagtatanong, “”kaya, mister sistema actor, bakit nais mong gamitin ang sistema? Ano ang halaga ay ang sistema na ito ay nagbibigay sa iyo?””
Ang susunod na hakbang, sa oras na iyong kinilala kung paano ang iyong mga aktor ay nakikipag-ugnayan sa sistema, ay do idokumento ang iyong kaso gamitin. Ang bawat kaso gamitin ay kailangang mai-dokumentado na may ang daloy ng mga pangyayari, at ito ay tapos na mula sa punto ng aktor ng view. Dapat itong detalye kung ano ang sistema ay dapat magbigay sa mga artista kapag ang paggamit kaso ay pinaandar. Kadalasan ito ay magpapakita sa mga bagay tulad ng kung paano ang paggamit kaso ay nagsisimula at matapos. Anong mga bagay ang ginagawa na gamitin ang kaso ay may sa gawin? Magkakaroon ka sa normal na daloy ng mga kaganapan (ang tinatawag ko ang “”happy days”” sitwasyon), kung saan lahat ng bagay ay gumagana. Pagkatapos ay makikita mo makuha ang abnormal daloy ng mga kaganapan, ang “”araw ng kagipitan”” sitwasyon. Ano ang mangyayari kapag ang sistema ay hindi gumagana? Ko na natagpuan sa pamamagitan ng documenting ang aking daloy ng mga kaganapan na ako ay laging magsimula sa ang masasayang araw na sitwasyon.
Kuning halimbawa, paglalakad hanggang sa isang automated teller machine. Lakad ka hanggang sa ang ATM at ipasok ang iyong card. Ito ay humihingi para sa iyong PIN number. Ipasok mo ito, at ikaw ay tinanong kung ano ang nais mong gawin. sasabihin mo “”Gusto ko ng ilang pera.”” Ito ay humihingi kung saan ang pera ay dapat na kinuha mula sa. sabihin sa iyo upang sakupin mula sa iyong checking account. Ito ay humihingi kung magkano. Sabihin mo $ 100.00. Pagkatapos magic ang mangyayari â € | ay nagbibigay sa iyo $ 100.00. Pagkatapos ito nagtatanong kung gusto mo ng isa pang transaksyon. Sabihin mo no. Ito ay nagbibigay sa mo ang iyong card sa likod, ay nagbibigay sa iyo ng isang resibo, at ang transaksyon ay higit sa. Iyan ang masayang araw na sitwasyon.
Second sitwasyon. Pumunta ka hanggang sa ang ATM, ipasok ang iyong card, at ipasok ang iyong PIN. Ang ATM ay nagsasabi sa iyo ito ay ang maling PIN. Ipasok mo ang iyong numero ng muli. Muli ikaw ay sinabi na ang PIN ay hindi tama. Mo Sa aking kurso registration halimbawa, halimbawa, maaari mong makita na may mga isang pulutong ng mga “”kung X pagkatapos Y”” daloy ng trabaho. Iyan ay kung saan mo nais ang iyong customer upang makatulong sa iyo out. Pagkuha kasunduan maaga nangangahulugan na ang iyong customer nauunawaan ang mga sitwasyong ito at nagsasabing “”yes, ito ay kung ano ang gusto namin.”” Gamitin ang mga kaso ay mahusay na paraan upang matiyak na ang kung ano ang ikaw ay gusali ay talagang kung ano ang customer ay nais, dahil ipakita nila ang mga aktor, ang mga kaso na paggamit, at ang relasyon sa pagitan nila.
Figure 5: Gamitin ang kaso diagram
Kaya kami ay may isang mahusay na diagram na graphically nagpapakita sa akin kung ano? Ang sagot ay simple â € “”ito ay isang mahusay na diagram na nagpapakita ng isang magandang pangkalahatang-ideya ng sistema. Ipinapakita nito kung ano ang labas ng system (aktor) at ang pag-andar na ang sistema ay dapat magbigay ng (mga kaso na paggamit). Kung may isang legacy system na kailangan mo upang isaalang-alang, narito ang kung saan mo haharapin ang mga ito. Pagpilit sa akin na magtrabaho sa ganitong mga uri ng mga interface masyadong maaga sa proyekto ay nangangahulugan na hindi ko ay nahaharap sa pag-asam ng paghihintay hanggang coding ay nagsisimula upang malaman kung paano ako pagpunta sa makipag-usap sa na itim na kahon na hindi ko maaaring baguhin .
Isa pang bagay na dapat mong malaman tungkol sa mga kaso gamitin ay ang gamitin kaso makinabang. Ito ay ang “”kung paano”” dahil sa paggamit kaso. Ito ay karaniwan ay isang bucket na naglalaman ng tatlong iba’t ibang uri ng mga diagram: sequence diagram, pakikipagtulungan diagram, at isang klase diagram na tinatawag naming isang view ng mga kalahok na mga klase. Gamitin ang kaso realizations ay isa lamang ng isang paraan ng pagpapangkat-sama ng isang bilang ng mga artifacts na may kaugnayan sa disenyo ng isang gamitin kaso.
sequence diagram
Sequence diagram ipakita pakikipag-ugnayan object nakaayos sa isang oras sequence. Maaari ko bang gamitin ang daloy ng mga pangyayari upang matukoy kung ano mga bagay at mga pakikipag-ugnayan ang ang kailangan ko upang makamit ang pag-andar na tinukoy sa pamamagitan ng daloy ng mga kaganapan.
Figure 6: Sequence diagram
Figure 6 ay nagpapakita kung paano ang isang estudyante matagumpay makakakuha idinagdag sa isang kurso. Ang mag-aaral (sabihin tumawag sa kanya Joe) pumupuno sa ilang mga impormasyon at submits ang form. Ang form na ito pagkatapos talks sa manager at nagsasabing “”si Joe sa Math 101.”” manager ay nagsasabi Math 101 na ito ay upang magdagdag ng isang mag-aaral. Math 101 magsabi sa Section 1 “”ay binuksan mo?”” Sa kasong ito, Section 1 sagot na ang mga ito bukas, kaya Math 101 nagsasabi seksyon 1 upang magdagdag student na ito. Muli, sequence diagram ay mahusay na mga kasangkapan sa simula dahil sila ipakita sa iyo at ang iyong mga customer step-by-step kung ano may mangyari.
Mula sa isang pag-aaral na punto ng view, na nahanap ko sa mga nakaraang taon na sequence diagram ay lubhang makapangyarihan sa pagtulong sa akin magmaneho kinakailangan; lalo kinakailangan na mahirap upang mahanap. kinakailangan ng gumagamit interface, halimbawa, ay kilalang-kilala dahil palagi kang mukhang upang makakuha ng mga kinakailangan na lamang ay hindi testable. Ang isang karaniwang kinakailangan UI tulad nito ay “”ang sistema na ito ay magiging user-friendly.”” Ilan sa inyo ay may matugunan ang isang friendly computer? Isa sa mga benepisyo ng mga uri ng diagram ay na ang bawat linya na nagmumula sa isang artista na kumakatawan sa isang tao, ay nagsasabi sa iyo na ang isang bagay sa iyong UI ay may upang magbigay ng isang kakayahan na kailangan ng taong iyon. Sa ibang salita, maaari mong gamitin ang sequence diagram upang himukin out testable kinakailangan user interface.
Sequence diagram ay, samakatuwid, ang mahusay para sa pagpapakita ng kung ano ang nangyayari sa, para sa pagmamaneho out kinakailangan, at para sa mga nagtatrabaho sa mga customer. Iyon ay karaniwang mga leads sa tanong na, bagaman, kung gaano karaming mga kailangan mo upang lumikha? Ang aking sagot ay, “”hanggang sa gawin mo sapat na.”” Ikaw ay pagpunta upang malaman kung kailan gagawin mo sequence diagram na maabot mo ang isang punto kung saan hindi ka sa paghahanap ng anumang mga bagong bagay, hindi paghahanap ng anumang mga bagong mensahe, at na tina-type mo ang parehong bagay nang paulit-ulit. Sa halimbawa ng Joe pagsali Math 101, nalaman natin na ang proseso ay ang parehong kung Joe nais na sumali History 101. Kaya, patakaran ng hinlalaki, gawin ang isang sequence diagram para sa bawat pangunahing daloy ng bawat paggamit kaso. Gawin ang isang sequence diagram para sa mataas na antas, peligroso sitwasyon, at na dapat ay sapat. Iyan ay kung gaano karaming mga sequence diagram gagawin ko.
na tandaan dito, ay na ang isang pakikipagtulungan diagram ay lamang ng isang iba’t ibang mga view ng isang sitwasyon at maaari kang bumalik-balik sa pagitan sequence diagram at pakikipagtulungan diagram upang makuha ang view na pinakamahusay na naglalarawan ng iyong point.
Paminsan-minsan, maaari mong marinig ang pariralang “”diagram pakikipag-ugnayan.”” Minsan ang mga tao ay sama-sama-refer sa isang pakikipagtulungan diagram at isang sequence diagram bilang isang pakikipag-ugnayan diagram.
Class diagram
Ang isang klase ay isang koleksyon ng mga bagay na may karaniwang mga istraktura, karaniwang pag-uugali, mga karaniwang mga relasyon, at mga karaniwang semantika. Hanapin mo ang mga ito sa pamamagitan ng pagsusuri ang mga bagay sa pagkakasunod-sunod at pakikipagtulungan diagram, at sila ay kinakatawan sa UML bilang isang parihaba na may tatlong compartments.
Figure 8: Classes
Ang unang kompartimento ay nagpapakita ng mga pangalan ng klase, ang pangalawang ay nagpapakita ng kanyang istraktura (katangian), at ang ikatlong ay nagpapakita ng kanyang pag-uugali (operasyon). Ang mga compartments maaaring pinigilan, gayunpaman, sa gayon ay maaari mong makita lamang ang pangalan, lamang ang pangalan at ang mga katangian, o lahat ng tatlong. Isang bagay na dapat mo ring malaman na ito ay mahalaga, kapag pagbibigay ng pangalan sa mga klase, gamitin ang bokabularyo ng domain at pumili ng isang standard. Halimbawa ito, ang aking mga klase ay ang lahat ng isahan nouns na nagsisimula sa isang malaking titik. Maaari mong piliin na gawin ito sa ibang paraan, at na ay hindi mahalaga. Ano ang bagay ay na bago ang iyong proyekto kang pumili ng isang pamantayan at dumikit sa mga ito nang sa gayon ay ang lahat ng bagay ay pare-pareho sa buong proyekto.
Class diagram ipakita sa iyo ang mga static na katangian ng iyong system. Ang mga diagram ipakita ang pagkakaroon ng mga klase at ang kanilang relasyon sa lohikal na tingnan ng isang system. Magkakaroon ka ng maraming klase ng mga diagram sa isang modelo.
Ang mga elemento UML modeling natagpuan sa klase diagram ay kinabibilangan ng:
Klase at kanilang mga istraktura at pag-uugali.
Association, pagsasama-sama, dependency at ng mga mana relasyon.
Maraming iba’t ibang klase at pag-navigate tagapagpabatid
Role pangalan.
Tingnan ang Figure 9. diagram na ito ay nagpapakita operasyon (pag-uugali): kung ano ang isang bagay na sa klase na maaaring gawin. Mahanap ko ang aking mga operasyon sa pamamagitan ng pagtingin sa aking mga pakikipag-ugnayan diagram.
Figure 9: Operations
Narito ako sinasabi na kailangan ko para ma-hilingin sa registration manager upang magdagdag ng isang mag-aaral upang Math
101. Iyan ay pagpunta sa isalin sa isang operasyon na tinatawag na “”addCourse.””
Ang istraktura ng isang klase ay kinakatawan ng mga katangian nito. Kaya kung paano ko mahahanap ang aking katangian? Sa pamamagitan ng pakikipag-usap sa mga eksperto domain. Sa pamamagitan ng pagtingin sa aking mga pangangailangan. Sa aking halimbawa, malaman ko na ang bawat kurso handog ay may isang numero, isang lokasyon, at isang pagkakataon. Ito isasalin sa tatlong katangian.
klase. (Kinakatawan sa UML bilang isang linya pagkonekta ang kaugnay na mga klase na may isang brilyante sa tabi ng klase na kumakatawan sa kabuuan.)
â € ¢ Dependency â € “”isang mas mahinang form na nagpapakita ng relasyon sa pagitan ng isang client at isang supplier kung saan ang client ay walang semantiko kaalaman ng supplier. A dependency nagsasabing “”Kailangan ko ang iyong mga serbisyo, ngunit hindi ko alam na umiiral sa iyo.”” (Kinakatawan sa UML bilang dashed linya na tumuturo mula sa client sa tagapagtustos.)
Upang makahanap ng mga relasyon, sa sandaling muli, pumunta ako pabalik sa aking sequence diagram. Kung ang dalawang mga bagay na kailangan upang “”makipag-usap””, doon ay dapat na isang paraan upang gawin ito (ibig sabihin, ang isang relasyon sa pagitan ng kanilang mga klase).
Ako ay karaniwang simulan out at gumawa ng lahat isang kapisanan. Bilang ako ng paggawa nang higit pa pag-aaral, maaaring ko mahahanap ang Mayroon akong isang pagsasama-sama dahil ako pagpunta sa may upang alagaan ng isang magulang-anak relasyon. Kung makuha ko sa phase disenyo, hanapin ko out na hindi ko maaaring kailangan ng isang kapisanan dahil ang isang tao sino pa ang paririto ay pagpunta sa pumasa na object sa isa sa aking mga pamamaraan â € “”kaya ko gawin itong isang dependency.
Figure 11: Relationships
Sa Figure 11 Nakikita mo baga ang relasyon. Bilang association sabi ng Professor maaaring makipag-usap sa Course aalok, at ang Course Offering maaaring makipag-usap sa Professor. Mga mensahe ay maaaring pinasimulan at data ay maaaring dumaloy mula sa anumang direksyon. Pagsasama-sama ay ipinapakita sa pamamagitan ng pagkakaroon ng brilyante sa dakong buong â € “”sa kasong ito ng isang Course ay binubuo ng Course Offerings. Ang dahilan para sa pagsasama-sama ito ay upang sabihin sa aking mga developer na kung sila makakuha ng alisan ng Course na ito, ang mga ito ay malamang na may sa gawin ang isang bagay espesyal na may mga Alay Course. Dependencies ay ipinapakita bilang isang dashed linya. Ito ay nagsasabi na ang registration manager ay depende sa mga Schedule Algorithm na gawin ng isang bagay. Ang Schedule Algorithm ay alinman sa isang parameter sa isa sa mga pamamaraan o ay ipinahayag sa isang lugar lamang ng isa sa mga pamamaraan ng Registration Manager.
Maraming iba’t ibang klase at Navigation
Maraming iba’t ibang klase tumutukoy kung gaano karaming mga bagay lumahok sa isang relasyon. Ito ay ang bilang ng mga kaso ng isang klase na may kaugnayan sa isang pagkakataon ng ang iba pang mga klase. Para sa bawat association at pagsasama-sama, mayroong dalawang multiplicity desisyon upang gumawa: isa para sa bawat dulo ng relasyon. Maraming iba’t ibang klase ay kinakatawan bilang isang numero at isang * ay ginagamit upang kumatawan sa isang takot na dami ng marami.
Figure 12: Maraming iba’t ibang klase at pag-navigate
One Professor Object ay may kaugnayan sa zero-to-apat na Course Offering Objects. One Course Nag-aalok ng Object ay may kaugnayan sa eksaktong isang Professor Bagay. Gamitin ko ito upang tumingin sa at matiyak na ito humahawak sa aking mga pangangailangan. Maaari ko bang maging isang Course Offering at team-itinuro sa pamamagitan ng grupo ng mga professors? Hindi, dahil ito sabi ni ang maaari kong lamang magkaroon ng isang propesor. Maaari ko bang maging isang propesor at maging sa sabbatical? Oo, dahil ito sabi ni Mayroon akong isang zero hangga’t maaari course load. Gamitin ko maraming iba’t ibang klase medyo madalas upang makatulong sa akin simulan ang pagkuha at pagpapatupad ng aking mga patakaran ng negosyo. Kung mayroon kang, halimbawa, ang isang negosyo tuntunin na nagsasabing kailangan mong magkaroon ng hindi bababa sa 3 mga mag-aaral at hindi hihigit sa 10 para sa isang kurso na inaalok sa isang semester, ang mga maraming iba’t ibang klase numero sabihin sa akin ko na isinama nangagpupuno negosyo sa planong ito.
Navigation ay ipinapakita sa pamamagitan ng isang arrow, at bagaman asosasyon at pagsasama-sama ay bi-itinuro sa pamamagitan ng default, ito ay madalas na kanais-nais upang rendahan nabigasyon upang isang direksyon. Kapag navigation ay limitado, isang unahan ng pana ay idinagdag upang ipahiwatig ang navigational direksyon. Isa sa mga bagay na gagawin ko sa panahon ng pagtatasa at disenyo phases ay tumingin sa kung ano ang gusto kong maging uni-itinuro. Sa pamamagitan ng paglalagay ng mga arrow sa diagram na ito, sinasabi ko na ang Registration Manager ay maaaring magpadala ng mensahe sa Course, dahil ito nakakaalam ng Course umiiral na. Ngunit ang Course ay walang ideya na ang Registration Manager umiiral, kaya ang Course ay hindi maaaring simulan ang isang mensahe. Ngayon data ay maaaring dumaloy sa pagitan nila; halimbawa ang Registration Manager ay maaaring humiling sa Course kung ito ay bukas at ang Course ay maaaring sabihin na ito ay. Ngunit lamang ang Registration Manager ay maaaring magsimula na pag-uusap.
Malinaw na ang layunin dito ay upang makakuha ng maraming mga arrow bilang maaari mong sa oras na natapos mo na ang pagdisenyo, dahil sa ito ay isang lubhang mas madaling system upang mapanatili Inheritance ay ipinapakita na may isang tatsulok. Ito ay nagpapakita na ang Propesor ay isang Pagpaparehistro ng User, bilang ay ang Mag-aaral. Ngayon, ang isang salita ng babala. Mana ay kapaki-pakinabang, gayunpaman, ang layunin ay hindi upang gamitin ng mas maraming inheritance bilang iyong sistema ay magpapahintulot sa. Nakita ko ang ilang mga talagang brutal system kung saan sila ay nagkaroon ng mana 17-antas ng malalim. Kung sila ay nagbago sa isang bagay, ito ay naging isang kalamidad. Kaya ang patakaran ng hinlalaki ay ang paggamit ng mana lamang kapag ikaw ay tunay na kailangan ng mana sitwasyon.
State Transition Diagram
Ang isang estado transition diagram ay nagpapakita ng kasaysayan ng buhay ng isang naibigay na klase. Ipinapakita nito ang mga kaganapan na maging sanhi ng isang paglipat mula sa isang estado sa iba, at ang mga aksyon na nagresulta mula sa isang pagbabago ng estado.
Figure 14: State transition diagram
Gamitin ko ng estado diagram paglipat para sa mga klase object na ay karaniwang may isang pulutong ng mga dynamic na pag-uugali. button ay sa â € | ang pindutan Naka-off; Hindi ako pagpunta sa gawin ang isang tsart ng estado para sa mga ito. Ngunit object klase na magkaroon ng isang pulutong ng mga dynamic na pag-uugali, ako marahil pagpunta sa may sa tumingin sa ang estado ng mga bagay.
sisimulan ko sa pamamagitan ng pagpapakita ng isang estado, na kung saan ay isang bilugan tatsulok. Maaari ba akong magkaroon start estado, at maaari ba akong magkaroon stop estado, na kung saan ay ipinapakita bilang mga toro mata. Maaari ko ring magkaroon ng mga transition sa pagitan ng mga estado, o bantay transition (bagay na mangyayari kapag lamang kapag ang isang kondisyon ay totoo), o mga bagay na mangyayari kapag ako sa loob ng estado. tumingin ako sa diagram na ito at makita ang estado transition diagram para sa isang kurso na susunugin. Nagsisimula ito sa initialization ng estado, at manatili ako sa na estado hanggang sa makuha ko ang isang “”add mag-aaral”” message. Kung makuha ko ang mensaheng iyon, ay aking itinungo ang aking count ng mag-aaral sa zero at ako lumipat sa Open estado. Makakakita ka ng sa Figure 14 na mayroon akong isang entry, at ang dahilan kung bakit ito ay may ay na mayroon akong dalawang paraan ng pagkuha sa na estado. Sinasabi nito na kahit gaano ka dumating sa estado, gusto ko sa iyo upang irehistro ang mag-aaral. Kapag lumabas ako na estado, ang count pagbabago upang masubaybayan ang bilang ng mga mag-aaral sa kurso. Maaari ko bang panatilihin ang pagdaragdag ng mga mag-aaral hanggang sa makuha ko sa 10, at pagkatapos ko pumunta sa Close estado. Sa sandaling ang kurso ay finalized, paglipat ko sa mga stop estado. Hindi mahalaga kung nasaan ako pagkatapos, kung nakukuha ko ang Ikansela transition Event, abisuhan ko ang aking mga mag-aaral at pagkatapos ay lumipat sa stop estado.
Para sa mga klase object na may isang pulutong ng mga dynamic na pag-uugali, ito ay lubos na nagkakahalaga ito upang gawin ang isang estado diagram upang makakuha ng isang hawakan sa lahat ng bagay na may mangyari. Tanungin ang iyong sarili kung ano ang mangyayari kapag nakakuha ako ng message? Ano ang aking gagawin kapag nakukuha ko ang mensaheng ito? Ano mensahe sa ako ay may upang magpadala ng? Ang isang pulutong ng mga mensaheng iyon naging operasyon ng object klase, tulad ng sa halimbawa na ito kung saan magdagdag ng isang mag-aaral ay isang operasyon. Ang isang pulutong ng mga pagkilos na ito, tulad ng pagtatakda ng count, incrementing ang count, pagsuri sa count, ang mga lahat maging pribadong operasyon ng na partikular na bagay ng klase at isang estado diagram ay kung saan nakikita ko na.
Paano ko malalaman mo kung ikaw ay may isang dynamic na object klase? Muli, bumalik sa sequence diagram. Kung ikaw ay may isang bagay ng klase na sa isang pulutong ng mga sequence diagram at ito ay nakakakuha at pagpapadala ng isang pulutong ng mga mensahe, na ang isang magandang indikasyon ito ay isang medyo dynamic object klase at ito ay dapat marahil ay may isang tsart ng estado para sa mga ito. Din para sa pagsasama-sama, kung saan mayroon kang ang buong ng mga bahagi nito, ako ng isang tsart ng estado para sa bawat pinagsama-samang kabuuan. Gagawin ko ito dahil halos lahat na pinagsama-samang kabuuan ay madalas na responsable para sa pamamahala ng messaging, na ginagawang mas dynamic.
component diagram
Of course walang sistema ay maaaring binuo nang walang isinasaalang-alang ang pisikal na mundo. Iyan ay kung saan component diagram pumasok. Sila ay ginagamit upang ilarawan ang mga organisasyon at mga dependencies sa pagitan ng mga bahagi ng software, kabilang ang mga bahagi ng source code, magpatakbo ng oras bahagi, o isang executable component. Sangkap ay nagpapakita ng bilang ng isang malaking parihaba na may dalawang mas maliit na parihaba sa gilid, tulad ng nakikita sa Figure 15.
Figure 15: Components
Yaong pag-ikot bagay kumakatawan interface (madalas na tinatawag na lollipop notation). Sa kasong ito, ipakita nila na ang Register.exe ay nakasalalay sa mga interface sa parehong mga Course.dll at ang People.dll. Iyon ay nangangahulugang kung ang mga interface baguhin, ito ay makakaapekto sa Register.exe. Alam ko na mayroong panuntunang ito kapag ikaw ay gusali interface na nagsasabing “”ikaw ay hindi dapat baguhin ang interface.”” Ngunit kahit sino ang tunay na gawain na kung saan ang panuntunan na Ipinapatupad? diagram na ito ay nagsasabi sa amin kung ano interface ay ginagamit ng kung ano ang executables ay tumatakbo sa aking processors.
Figure 16: Deployment diagram
pagpapalawak UML
Ang huling bagay na gusto kong magbigay-diin ang tungkol sa UML ay na ito ay maaaring pinalawak. Kapag sila ay binuo ng UML, ito ay napaka-matalino na natanto na walang paraan na maaari nilang lumikha ng isang notation na maaaring mangyaring lahat ng tao sa lahat ng oras. Na anopa’t kanilang ibinigay sa amin ang konsepto ng isang estereotipo. A estereotipo nagsasabing maaari kong kumuha ng mga pangunahing elemento modeling at bigyan ito ng mas maraming kahulugan. Stereotypes ay maaaring gamitin upang uriin at palawigin asosasyon, mana relasyon, mga klase, at mga bahagi.
Figure 17: Web estereotipo halimbawa
Figure 17 ay nagpapakita ng mga diagram sa aming Web stereotypes. Ang isang Web page ay karaniwang may mga bagay-bagay na tumatakbo sa server at bagay-bagay na tumatakbo sa client. Kung ikaw ay gusali ng mga aplikasyon ng Web-based, kung ano ang tumatakbo sa client at ang server ay mahalaga sa buhay ng kahalagahan. Kaya kami ay may isang buong hanay ng mga stereotypes na ipakita na. Ang maliit na wheels kumakatawan sa mga bagay na tumatakbo sa sa server. Kaya sa pamamagitan lamang ng pagtingin sa ang isang ito diagram Maaari ko bang makita kung ano ang tumatakbo sa server, kung ano ang tumatakbo sa client, at kung ano ang negosyo bagay mayroon sila upang harapin.

“——————————————————————————————————————————————————

Tuki käännös: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”UML on standardi kieli määrittämisestä, visualisointiin, rakentamiseen, ja dokumentointi kaikki esineitä on ohjelmisto.””
aktiviteettikaavio
Looginen paikka aloittaa kävely läpi joitakin UML kaavioiden on katsomalla aktiviteettikaavio.
Kuva 2: Aktiivisuus kaavio
Aktiviteettikaavio osoittavat virtauksen ohjaus. Kuten kuvassa 2, voit nähdä toimintaa edustettuina pyöristetty suorakaide. Toiminta on tyypillisesti toiminta todetaan â € “”todetaan, että siirtyminen automaattisesti seuraavaan tilaan, kun toiminto on valmis. Täytetty ympyrä edustaa alkua aktiviteettikaavio â € “”jos ohjauksen kulku alkaa. Siirtymät esitetty nuolet osoittavat, miten siirtyä toiminnan aktiivisuutta. Synkronointi palkit osoittavat, miten toiminta tapahtuu rinnan. Voin vartija siirtyminen, jossa lukee “”Haluan sinun mennä tähän toimintaan vain, jos tämä ehto on tosi,”” ja voin näyttää missä se pysähtyy. Nyt jos olet tietyssä iässä, luultavasti katsomaan tätä toimintokaaviosuunnitteluun ja ajatella, “”hmm â € | joka näyttää vuokaavion.”” Ja se, mitä se on, paitsi en tee sitä alas ohjelmointitasolle. Tyypillisesti Käytän toimintokaaviosuunnitteluun melko varhain minun analyysi ja suunnittelu prosessi näyttää liiketoiminnan työnkulun. Otan myös käyttää niitä näyttää missä kukin oman käyttötapauksia voi olla toimintaa havainnollistaa, mitä käyttötapaus on tapahduttava. Olen myös käyttää aktiviteettikaavio osoittaa, miten asiat virtaavat välillä minun käyttötapauksia.
Mutta yksi suurista asioita UML on sen monipuolisuus. Joten vaikka käytän aktiviteettikaavio alussa elinkaaren, muut voivat käyttää niitä eri vaiheessa kokonaan. Olen nähnyt ihmiset käyttävät aktiviteettikaavio alas suunnittelun tasolle, jolla ne olivat hyvin monimutkainen joukko algoritmeja tietylle luokalle. Ja monet ihmiset käyttävät niitä näyttää virtauksen menetelmien välillä luokan.
systeemi. Toimijat ovat edustettuina tikku.
Kuva 4: Näyttelijöitä
Esimerkki työskentelin muodostavat tämän johdannon UML on pieni malli tietysti rekisteröintijärjestelmä. Joten tässä tapauksessa, ensimmäinen asia, jonka haluan tehdä, kun alkaa minun analyysi prosessi on kysyä, “”kuka vuorovaikutuksessa tämän järjestelmän?””
Kurssille ilmoittautuminen malli, olen kirjaaja, professori, ja opiskelija. Minulla on myös ulkoinen laskutusjärjestelmä. Tämä laskutusjärjestelmä myös katsotaan näyttelijänä. (Katso, näyttelijä ei tarvitse olla henkilö â € “”se on jotain, joka toimii vuorovaikutuksessa järjestelmän kanssa, mutta on järjestelmän ulkopuolella.)
Käyttötapaus on sarja toisiinsa liittyviä suorituksia toimijana järjestelmän dialogi. Tai laittaa se Englanti, käyttötapaus on kimpale toiminnallisuutta. Ja tässä on avain: se ei ole ohjelmistomoduuli â € “”se on jotain, joka antaa lisäarvoa näyttelijä.
Käyttötapauksia on esitetty soikio, ja helpoin tapa löytää ne on tarkastella kunkin oman toimijoiden ja kysyt miksi he haluavat käyttää järjestelmää. Minun tapauksessani, minun rekisterinpitäjä aikoo säilyttää opetussuunnitelman, minun professori aikoo pyytää lista, minun opiskelija ylläpitää aikataulu, ja minun laskutusjärjestelmä vastaanottaa laskutustiedot. Joten luon käyttötapaukset katsomalla sitä asiakkaan näkökulmasta ja kysyy, “”niin, mister järjestelmä näyttelijä, miksi haluat käyttää järjestelmää? Mitä arvoa tämä järjestelmä antaa sinulle?””
Seuraava askel, kun olet tunnistanut, miten toimijoiden välillä vuorovaikutuksessa järjestelmän kanssa, on tehdä asiakirja käyttötarkoituksia varten. Jokainen käyttötapaus on dokumentoitu virtaus tapahtumia, ja tämä tehdään siitä näyttelijän näkökulmasta. Sen pitäisi yksityiskohtaisesti, mitä järjestelmän on toimitettava toimija, kun Käyttötapauksen suoritetaan. Tyypillisesti se näyttää esimerkiksi, kuinka käyttötapaus alkaa ja päättyy. Mitkä asiat tarkoittaako tämä käyttötapaus on tehtävä? Sinulla on normaalia tapahtumien (mitä kutsun “”Happy Days”” skenaario), jossa kaikki toimii. Sitten saat epänormaali virtaus tapahtumien vuoksi “”sateinen päivä”” skenaario. Mitä tapahtuu, kun järjestelmä ei toimi? Olen löytänyt dokumentoimalla minun virtaus tapahtumia, jotka olen aina aloittaa onnellinen päivän skenaario.
Otetaan esimerkkinä, kävely jopa pankkiautomaatti. Kävelet asti ATM ja asettamalla kortin. Se kysyy PIN numeron. Voit kirjoittaa sen, ja kysyy, mitä haluat tehdä. Sanot “”Haluan rahaa.”” Se kysyy, missä rahat olisi otettava. Kerrot se ottaa sen oman tarkkailun huomioon. Se kysyy, kuinka paljon. Sanot $ 100.00. Sitten taika tapahtuu â € | se antaa sinulle $ 100.00. Sitten se kysyy haluatko toinen tapahtuman. Sanot ei. Se antaa sinulle kortin takaisin, antaa kuitin, ja kauppa on ohi. Se on onnellinen päivä skenaario.
Toinen skenaario. Menet jopa ATM, asettamalla kortin, ja anna PIN-koodi. ATM kertoo, että se on väärä PIN. Faksinumerotietosi uudelleen. Jälleen olet kertonut, että PIN-koodi on väärä. Sinä Minun tietenkin rekisteröinnin Esimerkiksi esimerkiksi, voit nähdä, että on olemassa paljon “”jos X niin Y”” työnkulkuja. Se missä haluat asiakas auttamaan teitä. Getting sopimus aikaisin tarkoittaa asiakkaan ymmärtää näitä skenaarioita ja sanoo “”kyllä, tämä on mitä me haluamme.”” Käyttötapauksia ovat hyvä tapa varmistaa, että mitä olet rakentamassa on todella, mitä asiakas haluaa, koska ne osoittavat toimijat, käyttötapaukset ja niiden väliset suhteet.
Kuva 5: Käyttötapauskaavio
Joten meillä on suuri kaavio, joka graafisesti osoittaa minulle mitä? Vastaus on yksinkertainen â € “”se on suuri kaavio, joka näyttää hyvän yleiskuvan järjestelmästä. Se osoittaa, mikä on järjestelmän ulkopuolella (toimijat) ja toiminnallisuutta, että järjestelmän on annettava (käyttötapauksia). Jos on sukupolven järjestelmän sinun täytyy ottaa huomioon, tässä missä käsitellä sitä. Pakottaa minut työskennellä näiden rajapinnoista hyvin hankkeen alkuvaiheessa tarkoittaa, että en kohtaamaan odotusajat kunnes koodaus alkaa selvittää, miten aion puhua että musta laatikko, että en voi muuttaa .
Yksi asia sinun tulisi tietää käyttötapauksia on käyttötapauksen toteutumista. Tämä on “”miten”” käytön tapauksessa. Se on yleensä ämpäri, joka sisältää kolme erilaista kaaviot: sekvenssikaaviot, yhteistyö kaaviot ja luokkakaavio jota kutsumme näkymä osallistuvien luokkiin. Käytä tapauksessa irtautumisia pohjimmiltaan tapa ryhmittää yhteen useita esineitä, jotka liittyvät suunnitteluun käyttötapaus.
sekvenssikaaviot
Sekvenssikaaviot osoittavat esineen vuorovaikutusta järjestetty aikajanalla. Voin käyttää virtausta tapahtumia mitkä kohteet ja vuorovaikutusta minun täytyy suorittaa toiminnallisuuden määritelty virtauksen tapahtumia.
Kuva 6: Sekvenssikaavio
Kuvio 6 esittää, kuinka opiskelija onnistuneesti saa lisätä kurssin. Opiskelijan (kutsukaamme häntä Joe) täyttää joitakin tietoja ja lähettää lomakkeen. Lomake sitten puhuu johtaja ja sanoo “”lisää Joe Math 101.”” Johtaja kertoo Math 101, että sen täytyy lisätä opiskelija. Math 101 sanoo Osa 1 “”ovat avaat?”” Tällöin 1 jakson vastauksissa, että ne ovat auki, joten Math 101 kertoo 1 jaksossa lisätä tämä opiskelija. Jälleen sekvenssikaaviot ovat loistavia työkaluja alussa, koska ne osoittavat sinun ja asiakkaan askel askeleelta, mitä on tapahtumassa.
Vuodesta analyysin näkökulmasta, olen löytänyt vuosien varrella, että sekvenssikaaviot ovat hyvin voimakkaita auttaa minua ajaa vaatimuksia; etenkin vaatimukset, joita on vaikea löytää. Käyttöliittymä vaatimukset, esimerkiksi, ovat tunnettuja, koska aina näyttävät saavan vaatimuksia, jotka ovat vain ole testattavissa. Yleinen UI vaatimus, kuten tämä on “”tämä järjestelmä on käyttäjäystävällinen.”” Kuinka moni teistä on tavannut ystävällinen tietokone? Yksi eduista tämäntyyppisten kaavioita on, että jokainen tuleva linja toimija, joka edustaa henkilö, kertoo, että jotain oman UI on tarjota ominaisuus tarvitaan kyseisen henkilön. Toisin sanoen, voit sekvenssikaaviot ajaa ulos testattavissa käyttöliittymä vaatimukset.
Sekvenssikaaviot ovat siis hyvä osoittaa, mitä tapahtuu, ajo vaatimuksista, ja työskennellä asiakkaiden. Tämä yleensä johtaa kysymykseen, vaikka kuinka monta tarvitset luoda? Vastaukseni on, “”kunnes teet tarpeeksi.”” Te tulette selville, kun teet sekvenssikaaviot että tulet kohtaan, jossa et löydä mitään uutta esineitä, ei löytää uusia viestejä, ja että kirjoitat saman asian uudestaan ja uudestaan. Esimerkissä Joe liittyä Math 101, saamme tietää, että prosessi olisi sama, jos Joe halusi liittyä History 101. Joten nyrkkisääntö, tee kaavio jokaiselle perusvirtauskaavio jokaisen käyttötapauksen. Tee kaavio korkean tason, riskialtista skenaarioita, ja sen pitäisi riittää. Niin monta sekvenssikaaviot teen.
muistaa tässä, on että yhteistyö kaavio on vain eri mieltä skenaario ja voit mennä edestakaisin sekvenssikaavioiden ja yhteistyö kaaviot saada mielestä parhaiten havainnollistaa viestisi.
Joskus saatat kuulla lause “”vuorovaikutus kaaviot.”” Joskus ihmiset kollektiivisesti viitata olioyhteistyökaavion ja sekvenssikaavio kuin yhteisvaikutusesitys.
luokkamalleista
Luokka on kokoelma esineitä yhteinen rakenne, yleinen käyttäytyminen, yhteisiä suhteita, ja yhteinen semantiikka. Löydät ne tutkimalla esineitä järjestyksessä ja yhteistyö kaaviot, ja ne ovat edustettuina UML kuin suorakulmion kolme lokeroa.
Kuva 8: Luokat
Ensimmäinen lokero näkyy luokan nimi, toinen näyttää sen rakenteen (määritteitä), ja kolmas osoittaa sen käyttäytyminen (toiminta). Nämä osastot voidaan vaimentaa, kuitenkin siten, että voit nähdä vain nimi, vain nimi ja attribuutteja, tai kaikki kolme. Yksi asia sinun pitäisi myös tietää, että on tärkeää, nimeämisessä luokat, käyttää sanastoa verkkotunnuksen ja valitse standardi. Tätä Esimerkiksi minun luokat ovat kaikki yksikössä substantiiveja, jotka alkavat isolla kirjaimella. Voit valita tehdä sen eri tavalla, ja että ei ole väliä. Mitä väliä on, että ennen projektin nostat standardin ja pysy siinä niin, että kaikki on yhdenmukainen projektin.
Luokkamallien näyttää staattinen luonne järjestelmään. Nämä kaaviot ilmenevät luokat ja niiden suhteet looginen kuva järjestelmästä. Sinulla on monia luokkamallien mallissa.
UML mallinnus elementtejä löytyy luokkamalleista ovat:
Luokat ja niiden rakennetta ja käyttäytymistä.
Association, yhdistäminen, riippuvuutta, ja perintö suhteita.
Moninaisuus ja navigointi indikaattoreita
Rooli nimiä.
Tutustu Kuva 9. Tässä kuvassa näkyvät toiminnot (käyttäytyminen): mitä kohde tässä luokassa voi tehdä. Löydän toimintaa tarkastelemalla minun vuorovaikutusta kaavioita.
Kuvio 9: Operations
Tässä en sano, että minun täytyy pystyä pyytämään rekisteröintijohtajana lisätä opiskelija Math
101. Se menee kääntää operaation nimeltä “”addCourse.””
Rakenne luokan edustaa sen ominaisuuksia. Joten miten löydän attribuutteja? Keskustelemalla verkkotunnuksen asiantuntijoita. Tarkastelemalla minun vaatimukset. Minun esimerkiksi opin, että jokainen kurssitarjonta on useita, sijainti ja aika. Tämä merkitsee ulos kolmea ominaisuutta.
luokat. (Edustettuina UML kuin viiva, joka yhdistää siihen liittyvät luokat timantti vieressä luokan edustaa koko.)
â € ¢ Riippuvuus â € “”lievempi muoto, joka esittää suhdetta asiakkaan ja toimittajan, joissa asiakas ei ole semanttinen tietojen mukaisesti. Riippuvuussuhde sanoo “”Tarvitsen palveluja, mutta en tiedä, että olet olemassa.”” (Edustettuina UML katkoviivana osoittaa asiakkaalta toimittajalle.)
Löytää suhteita, jälleen kerran, menen takaisin minun kaavio. Jos kaksi objektia täytyy “”puhua””, on oltava keino tehdä niin (eli suhde niiden luokat).
En yleensä aloittaa ja tehdä kaikki yhdistys. Kuten Teen enemmän analyysiä, saatan löytää Olen yhdistäminen koska aion olla huolehtia vanhemman ja lapsen suhdetta. Kun pääsen suunnitteluvaiheessa, sain tietää, että en ehkä tarvitse yhdistys, koska joku muu on menossa ohi, että esine eräs menetelmistä â € “”niin Teen sen riippuvuutta.
Kuva 11: Ihmissuhteet
Kuvassa 11 näet näitä suhteita. Koska yhdistys sanoo professori voi puhua Kurssitarjotinta, ja Kurssitarjotinta voi puhua professori. Viestejä voidaan aloittaa ja data voi virrata mistä tahansa suunnasta. Aggregaatiota näkyy jolla timanttien kohti koko â € “”tässä tapauksessa Kurssi koostuu Course Tuotteisiin. Syynä tähän yhdistäminen olisi kertoa kehittäjille, että jos he päästä eroon tästä Course, he luultavasti täytyy tehdä jotain erityistä kanssa Course Tuotteisiin. Riippuvuudet on esitetty katkoviivalla. Se sanoo, että rekisteröinti johtaja riippuu Aikataulu algoritmi tehdä jotain. Aikataulu Algoritmi on joko parametri yksi menetelmistä tai julistetaan paikallisesti yksi menetelmistä rekisteröintiä Manager.
Moninaisuus ja navigointi
Moninaisuus määrittelee kuinka monta esineitä osallistua suhteeseen. Se on määrä tapauksia yhden luokan liittyvän yksi esiintymä toisen luokan. Liitoittain ja yhdistäminen on kaksi moninaisuus päätöksiä tehdä: yksi kumpaankin päähän suhteen. Moninaisuus on edustettuna numero ja a * käytetään edustamaan lukuisia monia.
Kuva 12: moninaisuus ja navigointi
Eräs professori Object liittyy nollasta neljään Course Offering Objects. Yksi Kurssitarjotinta Object liittyy täsmälleen yksi professori Object. Käytän tätä tarkastella ja varmistaa, että tämä käsittelee minun vaatimuksia. Voinko olla kurssitarjonta ja on joukkue-opettaa joukko professoreita? Ei, koska tämä kertoo voin vain yksi professori. Voinko olla professori ja olla sapattivapaalla? Kyllä, koska tämä kertoo olen nolla mahdollisimman kurssin kuorman. Käytän moninaisuus usein auttaa minua aloittaa syömällä ja täytäntöönpanoa minun liiketoiminnan sääntöjä. Jos olet esimerkiksi yrityksen sääntö, joka sanoo sinun täytyy olla vähintään 3 opiskelijoille ja enintään 10 kurssi tarjotaan lukukauden, nämä moninaisuus numerot kerro Olen otettu, että perusedellytysten tähän suunnitelmaan.
Navigation on esitetty nuolella, ja vaikka yhdistysten ja koosteita ovat kaksisuuntaisia oletuksena, on usein toivottavaa rajoittaa navigointi yhteen suuntaan. Kun navigointi on rajoitettu, nuolenkärki lisätään osoittamaan navigoinnin suuntaan. Yksi niistä asioista, teen analyysin aikana ja suunnitteluvaiheessa on katsoa, mitä haluan olla yksisuuntainen. Laittamalla nuolen tähän kaavio, sanon, että Rekisteröinti Manager voi lähettää viestin Course, koska se tietää Course olemassa. Mutta kurssi ei ole ajatus siitä, että rekisteröinti Manager olemassa, joten kurssi voi aloittaa viestin. Nyt data voi virrata niiden välillä; esimerkiksi Rekisteröinti Manager voi kysyä Course jos se on auki ja Course voi sanoa, että se on. Mutta vain rekisteröinnistä Manager voi aloittaa että keskustelu.
Ilmeisesti tavoitteemme on saada niin monta nuolia kuin voit mennessä olet valmis suunnittelussa, koska se on paljon helpompi pitääkseen yllä Perintövero on esitetty kolmiolla. Tämä osoittaa, että professori on Rekisteröinti Käyttäjä, kuten Student. Nyt varoituksen sana. Perintö on kuitenkin hyödyllistä, tavoitteena on olla käyttämättä niin paljon perintönä järjestelmä sallii. Olen nähnyt joitakin todella julma järjestelmissä, joissa heillä oli perintö 17-tasoa syvä. Jos ne muutetaan yksi asia, siitä tuli katastrofi. Joten nyrkkisääntö on käyttää perintö vain kun todella eivät ole perintönä tilanne.
Tilasiirtymäkaavioissa
Tilasiirtymäkaaviona esittää elämän historiaa tietyn luokan. Se näyttää tapahtumat, jotka aiheuttavat siirtyminen tilasta toiseen, ja toimet, jotka johtuvat tilan muutoksen.
Kuva 14: Tilasiirtymäkaavio
Käytän tilasiirtymäkaavioissa kohteiden luokkaa, että on tyypillisesti paljon dynaamista käyttäytymistä. Painike on â € | painike on pois päältä; En aio tehdä valtion kaavion sitä. Mutta objektiluokat että on paljon dynaaminen käyttäytyminen, olen luultavasti täytyy tutkia valtioiden esineitä.
I aloittaa joka esittää tilaa, joka on pyöristetty kolmio. Voin olla alku valtiot, ja voin olla lopettaa tilat, jotka on esitetty sonnien silmät. Voin myös tilojen välisten siirtymien, tai vartija siirtymiä (mitä tapahtuu, kun vain silloin, kun ehto on tosi), tai mitä tapahtuu kun olen sisällä valtion. Katson tätä kaavio ja nähdä tilakaavio varten kurssitarjonta. Se alkaa alustuksen tilassa, ja pysyn siinä tilassa, kunnes saan “”lisää opiskelijan”” -viestin. Kun saan viestin, minä käänsin lasken opiskelija nollaan ja minä siirtyminen Open tilaan. Näet kuvan 14 että minulla on merkintä, ja miksi se on, että minulla on kaksi tapaa saada tuohon tilaan. Siinä sanotaan, että vaikka kuinka tulet tilaan, haluan sinun rekisteröidä opiskelijalle. Kun suljen että valtio, count muutokset seurata opiskelijoiden määrä aikana. Voin pitää lisätä opiskelijoiden kunnes saan 10, ja sitten menen Close tilaan. Kun kurssi on viimeistelty, minä siirtyäkseen pysäytystilassa. Ei ole väliä missä olen silloin, jos saan Peruuta Tapahtuma siirtyminen, minä ilmoittaa minun opiskelijat ja sitten siirtyä stop tilaan.
Sillä objektiluokat että on paljon dynaamisen käyttäytymisen, se on sen arvoista tehdä tilakaavio saada käsitellä kaikesta, on tapahduttava. Mieti, mitä tapahtuu, kun saan viestin? Mitä teen, kun saan viestin? Mitä viestejä olen lähettää? Paljon näiden viestien tullut toiminnan objektin luokka, kuten tässä esimerkissä, jossa lisätään opiskelija on toiminnassa. Monet näistä toimista, kuten asetus laskea, monesko laskea, tarkkailun count, nämä kaikki tulevat yksityiset toiminnot kyseisen esineen luokka ja tilakaavio on, jos näen sen.
Mistä tiedät, jos olet dynaaminen objekti luokka? Jälleen kerran, palaa sekvenssikaaviot. Jos olet objektin luokka, joka tällä on paljon sekvenssikaaviot ja se alkaa ja lähettää paljon viestejä, se on hyvä osoitus se on melko dynaaminen objekti luokka ja sen olisi luultavasti tilaan kaavion sitä. Myös aggregoinneista, jossa on koko sen osien teen tila kaavio jokaiselle aggregaatin koko. Teen tämän lähinnä siksi, että yhteenlaskettu koko on usein vastuussa viestipalvelu, joka tekee dynaaminen.
komponentti kaaviot
Tietenkään mikään järjestelmä voidaan rakentaa ottamatta huomioon fyysisessä maailmassa. Se kun komponentti kaavioita tulevat. Niitä käytetään kuvaamaan organisaatioiden ja välisten riippuvuuksien ohjelmistokomponentteja, myös lähdekoodi komponentteja, ajoaika komponentteja tai suoritettavan komponentti. Komponentit ovat ohjelmia yhtä suuri suorakulmio, jossa on kaksi pienempää suorakulmioita puolella, kuten kuvassa 15.
Kuvio 15: Komponentit
Nuo pyöreä asiat ovat rajapinnat (usein kutsutaan tikkari merkintätapa). Tässä tapauksessa ne osoittavat, että Register.exe riippuu rajapinnat sekä Course.dll ja People.dll. Tämä tarkoittaa, että jos nämä liitännät muuttuvat, se vaikuttaa Register.exe. Tiedän, että tämä sääntö, kun olet rakentaa rajapintoja, jossa lukee “”sinä saa muuttaa käyttöliittymän.”” Mutta ei kukaan todella toimivat, kun kyseinen sääntö pannaan täytäntöön? Tämä kaavio kertoo meille, mitä rajapintoja käyttävät mitä ajettavat ovat käynnissä minun prosessorit.
Kuva 16: Käyttökaavio
laajentaminen UML
Viimeinen asia, jonka haluan stressata UML on, että se voidaan laajentaa. Kun he rakensivat UML, ne viisaasti tajusi, että ei ollut mitenkään he voisivat luoda merkintä, joka voi miellyttää kaikkia ihmisiä koko ajan. Niin he antoivat meille käsite stereotypia. Stereotypia sanoo voin ottaa perus mallinnuksen elementti ja antaa sille enemmän merkitystä. Stereotypiat voidaan luokitella ja laajentaa yhdistysten, perintö suhteet, luokat, ja komponentteja.
Kuva 17: Web stereotypia esimerkki
Kuvio 17 esittää kaavion web stereotypioita. Web sivu on tyypillisesti tavaraa, joka toimii palvelimessa ja tavaraa, joka toimii asiakkaan. Jos olet rakennuksen Web-pohjaisia sovelluksia, mitä käynnissä asiakkaan ja palvelimen on erittäin tärkeää. Meillä on koko joukko stereotypioita, jotka osoittavat. Pienet pyörät edustavat asioita, jotka kulkevat palvelimelle. Joten vain katsomalla tämän yhden kaavion näen mitä toimii palvelimessa, mitä toimii asiakas, ja mitä liike esineitä heillä on käsiteltävä.

“——————————————————————————————————————————————————

Traduction de soutien: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”L’UML est le langage standard pour spécifier, visualiser, construire et documenter tous les artefacts d’un système logiciel.””
diagrammes d’activité
La logique de commencer la marche à travers quelques-uns des diagrammes UML est en regardant les diagrammes d’activité.
Figure 2: diagramme d’activités
Les diagrammes d’activité montrent le flux de contrôle. Comme le montre la figure 2, vous pouvez voir les activités représentées sous forme de rectangles arrondis. Les activités sont généralement des états d’action â € “”indique que la transition automatiquement à l’état suivant après l’action est terminée. Le cercle rempli représente le début du diagramme d’activité â € “”où le flux de contrôle commence. Transitions montrées comme des flèches montrent comment vous vous déplacez d’une activité à. barres de synchronisation montrent comment les activités se produisent en parallèle. Je peux garder une transition qui dit: «Je veux que vous alliez à cette activité que si cette condition est vraie,”” et je peux vous montrer où il arrête. Maintenant, si vous êtes un certain âge, vous aurez probablement regardez ce diagramme d’activité et de penser, “”hmm â € |. Qui ressemble à un organigramme”” Et c’est exactement ce qu’il est, sauf que je ne le fais pas vers le bas au niveau de la programmation. En règle générale, j’utilise un diagramme d’activité assez tôt dans mon analyse et la conception processus pour montrer workflow métier. Je vais également les utiliser pour montrer où chacun de mes cas d’utilisation pourrait être une activité pour illustrer ce cas l’utilisation doit se produire. Je l’utilise aussi des diagrammes d’activités pour montrer comment les choses circulent entre mes cas d’utilisation.
Mais l’une des grandes choses au sujet de l’UML est sa polyvalence. Ainsi, alors que j’utilise les diagrammes d’activité au début du cycle de vie, d’autres peuvent les utiliser dans une phase entièrement différente. J’ai vu des gens utiliser des diagrammes d’activité vers le bas au niveau de la conception où ils ont eu un ensemble très complexe d’algorithmes pour une classe particulière. Et beaucoup de gens les utilisent pour montrer le flux entre les méthodes d’une classe.
le système. Les acteurs sont représentés comme des chiffres de bâton.
Figure 4: Acteurs
L’exemple que je travaillais pour cette introduction à UML est un petit modèle d’un système d’enregistrement des cours. Donc, dans ce cas, la première chose que je ferais quand commence mon processus d’analyse est de demander, «qui va interagir avec ce système?””
Pour le modèle d’inscription aux cours, j’ai un registraire, un professeur et un étudiant. J’ai également un système de facturation externe. Ce système de facturation se qualifie aussi comme un acteur. (Voir, par un acteur ne doit pas nécessairement être une personne â € “”il est tout ce qui interagit avec le système, mais est en dehors du système).
Un cas d’utilisation est une séquence de transactions connexes effectuées par un acteur dans le système dans une boîte de dialogue. Ou, pour le dire en anglais, un cas d’utilisation est une partie de la fonctionnalité. Et voici la clef: il est pas un module â logiciel € “”il est quelque chose qui apporte de la valeur à l’acteur.
Les cas d’utilisation sont présentés sous forme d’ovales, et la meilleure façon de les trouver est de regarder chacun de vos acteurs et demandez-vous pourquoi veulent-ils utiliser le système. Dans mon cas, mon registraire va maintenir le programme, mon professeur va demander une liste, mon élève maintient le calendrier, et mon système de facturation reçoit les informations de facturation. Je crée mes cas d’utilisation en regardant du point de vue du client et de demander, “”ainsi, acteur du système de monsieur, pourquoi voulez-vous utiliser le système? Quelle est la valeur de ce système fournit pour vous?””
L’étape suivante, une fois que vous avez identifié la façon dont vos acteurs seront en interaction avec le système, est do documenter vos cas d’utilisation. Chaque cas d’utilisation doit être documenté avec le flux d’événements, et cela se fait à partir du point de vue de l’acteur. Il devrait en détail ce que le système doit fournir à l’acteur lorsque le cas d’utilisation est exécutée. En général, il montrera des choses comme la façon dont le cas d’utilisation commence et se termine. Qu’est-ce que les choses ne ce cas d’utilisation ont à faire? Vous aurez le flux normal des événements (ce que j’appelle le scénario “”jours heureux””), où tout fonctionne. Ensuite, vous aurez l’écoulement anormal des événements, le scénario «jour de pluie””. Qu’est-ce qui se passe lorsque le système ne fonctionne pas? Je l’ai trouvé en documentant mon flux d’événements que je commence toujours avec le scénario des jours heureux.
Prenons comme exemple, marcher jusqu’à un guichet automatique. Vous marchez jusqu’à l’ATM et insérez votre carte. Il demande votre numéro PIN. Vous entrez, et vous demande ce que vous voulez faire. Vous dites: «Je veux un peu d’argent.”” Il demande où l’argent devrait être prélevé. Vous lui demandez de le prendre à partir de votre compte-chèques. Il demande combien. Vous dites que 100,00 $. Puis la magie se produit â € | il vous donne 100,00 $. Ensuite, il vous demande si vous voulez une autre transaction. Vous dites non. Il vous donne votre carte arrière, vous donne un reçu, et la transaction est terminée. Voilà le scénario de jour heureux.
Deuxième scénario. Vous montez à l’ATM, insérez votre carte, et entrez votre NIP. L’ATM vous dit qu’il est le mauvais code PIN. Vous entrez à nouveau votre numéro. Encore une fois on vous dit que le code PIN est incorrect. Vous Dans mon cours exemple d’enregistrement, par exemple, vous pouvez voir qu’il ya beaucoup de “”si X alors Y”” workflows. Voilà où vous voulez que votre client pour vous aider. Obtenir un accord signifie tôt votre client comprend ces scénarios et dit «oui, voilà ce que nous voulons.”” Les cas d’utilisation sont une excellente façon de veiller à ce que ce que vous construisez est vraiment ce que le client veut, car ils montrent les acteurs, les cas d’utilisation, et les relations entre eux.
Figure 5: Utilisez le diagramme de cas
Donc, nous avons un grand diagramme moi ce que montre graphiquement? La réponse est simple â € “”il est un grand diagramme qui montre une bonne vue d’ensemble du système. Il montre ce qui est en dehors du système (acteurs) et la fonctionnalité que le système doit fournir (cas d’utilisation). S’il y a un système d’héritage que vous devez prendre en considération, voici où vous traitez avec elle. me forçant à travailler avec ces types d’interfaces très tôt dans le projet signifie que je ne serai pas confronté à la perspective d’attendre jusqu’à ce que commence le codage de comprendre comment je vais parler à cette boîte noire que je ne peux pas changer .
Une autre chose que vous devez savoir sur les cas d’utilisation est le cas d’utilisation réalisation. Ceci est le «comment» de l’utilisation cas. Il est généralement un seau qui contient trois types de diagrammes: diagrammes de séquence, diagrammes de collaboration, et un diagramme de classes que nous appelons une vue des classes participantes. Utilisez réalisations de cas sont essentiellement un moyen de regrouper un certain nombre d’artefacts liés à la conception d’un cas d’utilisation.
diagrammes de séquence
Les diagrammes de séquence montrent les interactions d’objets disposés en une séquence temporelle. Je peux utiliser le flux d’événements pour déterminer quels objets et les interactions que je devrai accomplir la fonctionnalité spécifiée par le flux d’événements.
Figure 6: diagramme de séquence
La figure 6 montre comment un étudiant avec succès est ajouté à un cours. L’étudiant (appelons-le Joe) remplit quelques informations et soumet le formulaire. Le formulaire parle alors au gestionnaire et dit “”ajouter Joe à Math 101.”” Le gestionnaire dit Math 101 qu’il doit ajouter un étudiant. Math 101 dit à la section 1 «êtes-vous ouvert?”” Dans ce cas, la section 1 réponses qu’ils sont ouverts, alors Math 101 indique la section 1 pour ajouter cet étudiant. Encore une fois, les diagrammes de séquence sont d’excellents outils au début parce qu’ils vous et votre client montrent étape par étape ce qui doit arriver.
D’un point de vue de l’analyse, je l’ai trouvé au fil des ans que les diagrammes de séquence sont très puissants pour me aider à conduire des exigences; en particulier les exigences qui sont difficiles à trouver. exigences de l’interface utilisateur, par exemple, sont connus parce que vous semblez toujours d’obtenir des exigences qui ne sont tout simplement pas testable. Une exigence de l’interface utilisateur commune comme celui-ci est “”ce système est facile à utiliser.”” Combien d’entre vous ont rencontré un ordinateur convivial? L’un des avantages de ces types de diagrammes est que chaque ligne provenant d’un acteur qui représente une personne, vous dit que quelque chose dans votre interface utilisateur doit fournir une capacité nécessaire par cette personne. En d’autres termes, vous pouvez utiliser des diagrammes de séquence pour chasser les exigences de l’interface utilisateur testables.
Les diagrammes de séquence sont, par conséquent, bon pour montrer ce qui se passe, pour la conduite des exigences, et pour travailler avec les clients. Cela conduit généralement à la question, bien que, de combien avez-vous besoin de créer? Ma réponse est, “”jusqu’à ce que vous faites assez.”” Vous allez savoir quand vous faites des diagrammes de séquence que vous atteignez un point où vous ne trouvez pas de nouveaux objets, de ne pas trouver de nouveaux messages, et que vous tapez la même chose encore et encore. Dans l’exemple de Joe joindre Math 101, on apprend que le processus serait le même si Joe voulait rejoindre Histoire 101. Donc, règle générale, faire un diagramme de séquence pour chaque flux de base de tous les cas d’utilisation. Faites un diagramme de séquence pour de haut niveau, des scénarios à risque, et cela devrait être suffisant. Voilà combien schémas séquence que je fais.
de se rappeler ici, est que le diagramme de collaboration est juste un point de vue différent d’un scénario et vous pouvez aller et venir entre les diagrammes de séquence et les diagrammes de collaboration pour obtenir la vue qui illustre le mieux votre point.
De temps en temps, vous pourriez entendre l’expression «diagrammes d’interaction.”” Parfois, les gens collectivement référence à un diagramme de collaboration et d’un diagramme de séquence comme un diagramme d’interaction.
diagrammes de classes
Une classe est une collection d’objets avec structure commune, un comportement commun, des relations communes, et une sémantique commune. Vous les trouverez en examinant les objets en séquence et de collaboration des diagrammes, et ils sont représentés dans l’UML comme un rectangle avec trois compartiments.
Figure 8: Classes
Le premier compartiment indique le nom de la classe, la seconde montre sa structure (attributs), et la troisième montre son comportement (opérations). Ces compartiments peuvent être supprimés, cependant, de sorte que vous pouvez voir juste le nom, juste le nom et les attributs, ou les trois. Une chose que vous devez également savoir est qu’il est important, pour nommer les classes, pour utiliser le vocabulaire du domaine et de choisir un standard. Pour ce cas, mes cours sont tous les noms singuliers qui commencent par une lettre majuscule. Vous pouvez choisir de le faire différemment, et que n’a pas d’importance. Ce qui importe est que, avant votre projet, vous choisissez un standard et rester avec elle pour que tout soit uniforme dans tout le projet.
Class Diagrams vous montrer la nature statique de votre système. Ces diagrammes montrent l’existence des classes et de leurs relations dans la vue logique d’un système. Vous aurez beaucoup de diagrammes de classes dans un modèle.
Les éléments de modélisation UML trouvés dans les diagrammes de classes comprennent:
Les classes et leur structure et leur comportement.
relations d’association, l’agrégation, la dépendance, et d’héritage.
indicateurs de Multiplicité et de navigation
Les noms des rôles.
Jetez un oeil à la figure 9. Ce diagramme montre les opérations (comportement): ce qu’un objet de cette classe peut faire. Je trouve mes opérations en regardant mes interactions diagrammes.
Figure 9: Opérations
Ici, je veux dire que je dois être en mesure de demander au gestionnaire d’enregistrement pour ajouter un étudiant à Math
101. Ce qui va se traduire par une opération appelée “”addCourse.””
La structure de la classe est représentée par ses attributs. Alors, comment puis-je trouver mes attributs? En parlant à des experts du domaine. En regardant mes exigences. Dans mon exemple, j’apprendre que chaque offre de cours a un certain nombre, un emplacement et un temps. Cela se traduit par trois attributs.
des cours. (Représenté dans le langage UML comme une ligne reliant les classes associées avec un diamant à côté de la classe représentant l’ensemble).
â € ¢ La dépendance â € “”une forme plus faible montrant la relation entre un client et un fournisseur où le client n’a pas connaissance sémantique du fournisseur. Une dépendance dit: «Je besoin de vos services, mais je ne sais pas que tu existes.”” (Représenté dans l’UML comme une ligne en pointillés pointant du client au fournisseur.)
Pour trouver des relations, encore une fois, je reviens à mon diagramme de séquence. Si deux objets doivent «parler», il doit y avoir un moyen de le faire (par exemple, une relation entre leurs classes).
Je commence généralement sortir et faire tout une association. Comme je fais une analyse, je pourrais trouver j’ai une agrégation parce que je vais devoir prendre soin d’une relation parent-enfant. Quand je rentre dans la phase de conception, je trouve que je ne pourrais pas besoin d’une association parce que quelqu’un d’autre va passer cet objet dans un de mes méthodes â € “”donc je fais une dépendance.
Figure 11: Relations
Dans la figure 11 vous voyez ces relations. Comme association dit le professeur peut parler au cours d’offre, et le cours offre peut parler au professeur. Les messages peuvent être initiés et les données peuvent circuler dans toutes les directions. L’agrégation est représentée en ayant le diamant vers l’ensemble â € “”dans ce cas, un cours est composé de cours offerts. La raison de cette agrégation serait de dire à mes développeurs que s’ils se débarrasser de ce cours, ils vont probablement avoir à faire quelque chose de spécial avec les offres de cours. Les dépendances sont présentés comme une ligne en pointillés. Il est dit que le gestionnaire d’enregistrement dépend de l’algorithme de l’annexe de faire quelque chose. L’annexe Algorithme est soit un paramètre à l’une des méthodes ou est déclaré localement par l’une des méthodes du gestionnaire d’enregistrement.
Multiplicité et Navigation
Multiplicité définit le nombre d’objets participent à une relation. Il est le nombre d’instances d’une classe en relation avec une instance de l’autre classe. Pour chaque association et l’agrégation, il y a deux décisions multiplicité à faire: un pour chaque extrémité de la relation. Multiplicité est représenté par un numéro et un * est utilisé pour représenter une multiplicité de plusieurs.
Figure 12: Multiplicité et navigation
Un objet de professeur est lié à zéro à quatre offre de cours Objects. Un cours Offrant objet est lié à exactement un objet de professeur. J’utilise ceci pour regarder et veiller à ce que cela gère mes exigences. Puis-je être un placement de cours et d’être en équipe enseigné par un groupe de professeurs? Non, parce que cela me dit que je ne peux avoir un professeur. Puis-je être un professeur et d’être en congé sabbatique? Oui, parce que cela me dit que j’ai un zéro que possible la charge de cours. J’utilise la multiplicité assez souvent pour me aider à commencer à capturer et mettre en œuvre mes règles métier. Si vous avez, par exemple, une règle métier qui dit que vous devez avoir au moins 3 étudiants et pas plus de 10 pour un cours à être offert dans un semestre, ces chiffres multiplicité me dire que je l’ai incorporé cette règle de gestion dans ce plan.
La navigation est représenté par une flèche, et bien que les associations et les agrégations sont bidirectionnelles par défaut, il est souvent souhaitable de restreindre la navigation à une seule direction. Lorsque la navigation est limitée, une pointe de flèche est ajouté pour indiquer la direction de navigation. Une des choses que je fais lors de l’analyse et de conception des phases est de regarder ce que je veux être uni-directionnel. En mettant la flèche dans ce diagramme, je dis que le directeur de l’enregistrement peut envoyer un message au cours, car il sait existe le cours. Mais le cours n’a aucune idée que le gestionnaire d’enregistrement existe, de sorte que le cours ne peut pas lancer un message. les données peuvent maintenant circuler entre eux; par exemple, le directeur de l’enregistrement peut demander au cours si elle est ouverte et le cours peut dire qu’il est. Mais seul le directeur de l’enregistrement peut commencer cette conversation.
Évidemment, le but ici est d’obtenir autant de flèches que vous pouvez par le temps que vous avez la conception terminée, car il est un système beaucoup plus facile de maintenir l’héritage est représenté par un triangle. Cela montre que le professeur est un enregistrement de l’utilisateur, tout comme l’étudiant. Maintenant, un mot d’avertissement. L’héritage est utile, cependant, l’objectif est de ne pas utiliser autant héritage comme votre système permettra. Je l’ai vu certains systèmes très brutales où ils avaient 17 niveaux d’héritage profond. S’ils ont changé une chose, il est devenu un désastre. Donc, la règle de base est d’utiliser l’héritage que lorsque vous faites vraiment avoir une situation d’héritage.
Diagrammes de transition État
Un diagramme de transition d’état montre l’histoire de la vie d’une classe donnée. Il montre les événements qui provoquent une transition d’un état à un autre, et les actions qui résultent d’un changement d’état.
Figure 14: Diagramme de transition
J’utilise des diagrammes de transition d’état pour les classes d’objets qui ont généralement beaucoup de comportement dynamique. Le bouton est sur  € | le bouton est éteint; Je ne vais pas faire un tableau d’état pour elle. Mais les classes d’objets qui ont beaucoup de comportement dynamique, je vais probablement avoir à se pencher sur les états des objets.
Je commence en montrant un état, qui est un triangle arrondi. Je peux avoir des états de début, et je peux avoir des états d’arrêt, qui sont présentés comme des taureaux yeux. Je peux aussi avoir des transitions entre les états ou transitions de garde (des choses qui se produisent quand seulement quand une condition est vraie), ou des choses qui se produisent quand je suis à l’intérieur de l’état. Je regarde ce diagramme et voir le diagramme de transition d’état pour une offre de cours. Il commence dans l’état d’initialisation, et je reste dans cet état jusqu’à ce que je reçois un message “”ajouter étudiant””. Quand je reçois ce message, je mis mon compte de l’étudiant à zéro et je transition vers l’état ouvert. Vous verrez dans la figure 14 que j’ai une entrée, et la raison pour laquelle il est là est que j’ai deux façons d’entrer dans cet état. Il dit que peu importe comment vous entrez en l’état, je veux vous inscrire l’étudiant. Lorsque je quitte cet état, les changements de comptage pour garder une trace du nombre d’élèves dans le cours. Je peux continuer à ajouter des élèves jusqu’à ce que je reçois à 10, puis-je aller à l’état Close. Une fois le cours terminé, je transition vers l’état d’arrêt. Peu importe où je suis là, si je reçois la transition de l’événement Annuler, je préviens mes élèves, puis passer à l’état d’arrêt.
Pour les classes d’objets qui ont beaucoup de comportement dynamique, il vaut la peine de faire un diagramme d’état pour obtenir une poignée sur tout ce qui doit se produire. Demandez-vous ce qui se passe quand je reçois un message? Que dois-je faire lorsque je reçois le message? Quels messages pour que je dois envoyer? Un grand nombre de ces messages deviennent des opérations de la classe d’objet, comme dans cet exemple où ajouter un étudiant est une opération. Un grand nombre de ces actions, comme la mise au comte, incrémentation du compte, vérifier le nombre, ceux-ci deviennent toutes opérations privées de cette classe d’objet particulier et un diagramme d’état est là où je vois.
Comment savez-vous si vous avez une classe d’objet dynamique? Encore une fois, revenir sur les diagrammes de séquence. Si vous avez une classe d’objet qui se trouve sur un grand nombre de diagrammes de séquence et il est l’obtention et l’envoi d’un grand nombre de messages, qui est une bonne indication qu’il est une classe d’objet assez dynamique et il devrait probablement avoir une carte d’état pour elle. Aussi pour agrégations, où vous avez l’ensemble de ses parties, je fais un tableau d’état pour chaque agrégat complet. Je le fais surtout parce que l’ensemble global est souvent responsable de la gestion de la messagerie, ce qui le rend dynamique.
diagrammes de composants
Bien sûr, aucun système ne peut être construit sans tenir compte du monde physique. Voilà où les diagrammes de composants entrent en jeu. Ils sont utilisés pour illustrer les organisations et les dépendances entre les composants logiciels, y compris les composants de code source, des composants de l’exécution, ou un composant exécutable. Les composants sont montre qu’un grand rectangle avec deux petits rectangles sur le côté, comme on le voit sur la figure 15.
Figure 15: Composants
Ces choses rondes représentent les interfaces (notation souvent appelée sucette). Dans ce cas, ils montrent que le Register.exe dépend des interfaces à la fois au Course.dll et People.dll. Cela signifie que si ces interfaces changent, il aura un impact sur le Register.exe. Je sais qu’il ya cette règle lorsque vous construisez des interfaces qui dit «tu ne doit pas changer l’interface.”” Mais ce que quelqu’un travaille effectivement là où cette règle est appliquée? Ce schéma nous dit ce que les interfaces sont utilisées par ce executables sont en cours d’exécution sur mes processeurs.
Figure 16: Schéma de déploiement
Extension UML
La dernière chose que je tiens à souligner sur l’UML est qu’il peut être étendu. Quand ils ont construit l’UML, ils très sagement réalisé qu’il n’y avait aucun moyen ils pourraient créer une notation qui pourrait plaire à tout le monde tout le temps. Donc, ils nous ont donné l’idée d’un stéréotype. Un stéréotype dit que je peux prendre un élément de base de la modélisation et de lui donner plus de sens. Les stéréotypes peuvent être utilisés pour classer et d’étendre les associations, les relations d’héritage, les classes et les composants.
Figure 17: Web exemple de stéréotype
La figure 17 montre le schéma de nos stéréotypes sur le Web. Une page Web a généralement des choses qui fonctionne sur le serveur et d’autres choses qui fonctionne sur le client. Si vous construisez des applications basées sur le Web, ce qui est en cours d’exécution sur le client et le serveur est d’une importance vitale. Nous avons donc toute une série de stéréotypes qui montrent que. Les petites roues représentent des choses qui fonctionnent sur le serveur. Donc, juste en regardant celui-diagramme je peux voir ce qui fonctionne sur le serveur, ce qui fonctionne sur le client, et ce que les objets d’affaires qu’ils ont à traiter.

“——————————————————————————————————————————————————

Stipe oersetting: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”De UML is de standert taal foar opjefte, visualizing, oanlizzen, en te dokumintearjen alle keunstfoarwerpen fan in software systeem.””
Activity diagrammenName
De logyske plak om te begjinnen rinne troch guon fan ‘e UML diagrammenStencils is troch nei aktiviteit diagrammenStencils.
Figuer 2: Activity diagram
Activity skema ‘sjen litte de stream fan kontrôle. As yllustrearre yn Figure 2, kinne jo sjen aktiviteiten fertsjintwurdige as ôfrûne rjochthoeken. Aktiviteiten binne typysk aksje steaten â € “”stelt dat oergong automatysk nei de folgjende tastân nei de aksje is kompleet. De fol yn sirkel stiet foar it begjin fan ‘e aktiviteit diagram â € “”dêr’t de stream fan kontrôle start. Transysjes sjen as pylken litte sjen hoe’t jo ferhúzje fan aktiviteit nei aktiviteit. Syngronisaasje bars sjen hoe’t aktiviteiten barre yn parallel. Ik kin guard in oergong dy’t seit: “”Ik wol dy om te gean nei dizze aktiviteit allinne as dizze betingst is wier,”” en ik kin sjen litte jo wêr’t it ophâldt. No as jo binne in bepaalde leeftyd, dan sil nei alle gedachten sjoch op dizze aktiviteit diagram en tinke, “”hmm â € | dat sjocht as in stream chart.”” En dat is krekt wat it is, útsein ik net dwaan it del op de programmearring nivo. Typysk, ik brûk in aktiviteit diagram frij betiid op yn myn analyze en design proses te sjen saken workflow. Ik sil ek brûke se te sjen, dêr’t elk fan myn brûken gefallen soe wêze yn in aktiviteit te yllustrearjen wat gebrûk gefal hat te happen. Ik ek brûke aktiviteit diagrammenStencils om te sjen hoe’t dingen streame tusken myn gebrûk gefallen.
Mar ien fan de grutte dingen oer it UML is syn veelzijdigheid. Sa wylst ik brûke aktiviteit skema ‘oan it begjin fan’ e lifecycle, oaren kinne brûke se yn in oare faze folslein. Ik haw sjoen minsken brûke aktiviteit diagrammenStencils del op it ûntwerp nivo dêr’t se hiene in hiel yngewikkeld set Algorithmen foar in bepaalde klasse. En in protte minsken brûke se te sjen de stream tusken de metoaden fan in klasse.
it systeem. Akteurs binne fertsjintwurdige as stok figueren.
Figuer 4: Actors
It foarbyld dat ik wurke op foar dizze ynlieding ta UML is in bytsje model fan in kursus registraasje systeem. Sa yn dit gefal, it earste ding ik soe dwaan as begjint myn analyze proses is te freegjen, “”dy’t giet om ynteraksje mei dit systeem?””
Foar de kursus registraasje model, ik haw in griffier, in heechlearaar, en in learling. Ik ha ek in ekstern billing systeem. Dizze billing systeem ek yn oanmerking as akteur. (Sjoch, in akteur net te wêzen in persoan â € “”it is neat dat interacts mei it systeem, mar is bûten fan it systeem.)
In gebrûk gefal is in searje fan besibbe transaksjes útfierd troch in akteur yn it systeem yn in dialooch. Of, om it yn it Ingelsk, in gebruik saak is in brok fan funksjonaliteit. En hjir is de kaai: it is net in software module â € “”it is wat dat jout wearde oan de akteur.
Brûke gefallen wurde toand as ovals, en de maklikste manier om te finen se is te sjen op elk fan jimme akteurs en freegje josels wêrom hawwe se wolle brûke it systeem. Yn myn gefal, myn registrar giet te behâlden it kurrikulum, myn heechlearaar giet om freegje in roaster, myn learling ûnderhâldt it skema, en myn billing systeem krijt de billing ynformaasje. Sa ik meitsje myn brûken gefallen troch nei it út ‘e klant punt fan each en freegjen, “”sa, mister systeem akteur, wêrom dogge jo wolle brûke it systeem? Wat wearde hat dit systeem biede oan dy?””
De folgjende stap, ien kear jo ha identifisearre hoe’t jo akteurs wurde interacting mei it systeem, is taak gewest fryslân brûken gefallen. Elke gebrûk gefal moat it wurde dokumintearre mei de stream fan eveneminten, en dat wurdt dien út de akteur fan punt fan ferzje. It moat detail wat it systeem moat soargje foar de akteur doe’t it brûken gefal wurdt útfierd. Typysk sil litte saken as hoe’t it brûken saak begjint en einiget. Wat dingen hat dat gebrûk gefal hawwe te dwaan? Jo hawwe de normale flow fan eveneminten (wat ik neam it ‘happy dagen “”senario), dêr’t alles wurket. Dan dan krijst de ôfwikende stream fan eveneminten, de “”reinich dei”” senario. Wat bart der as it systeem net wurket? Ik haw fûn troch te dokumintearjen myn stream fan eveneminten dy’t ik altyd begjinne mei de lokkige dagen senario.
Nim as foarbyld, rinnen oant in automatisearre teller machine. Jo rinne oant de ATM en ynfoegje jo kaart. It freget om jo PIN nûmer. Jo komt it, en jo wurde frege wat jo graach te dwaan. Jo sizze “”ik wol wat jild.”” It freget wêr’t it jild moat wurde nommen út. Jo sizze it te nimmen it fan jo kontrolearje akkount. It freget hoefolle. Jo sizze $ 100.00. Dan magic bart â € | It jout jo $ 100.00. Dan freget as jo wolle in oar transaksje. Jo sizze gjin. It jout jo jo kaart werom, jout jo in ûntfangst, en de transaksje is oer. Dat is de lokkige dei senario.
Twadde senario. Jo geane op nei de pinautomaat, ynfoegje dyn kaart, en folje dyn PIN. De ATM fertelt jo dat is de ferkearde PIN. Jo folje dyn nûmer wer. Wer jo wurde ferteld dat de PIN is ferkeard. Jo Yn myn rin registraasje bygelyks, bygelyks, kinne jo sjen dat der in protte “”as X dan Y”” workflows. Dat is wêr’t jo wolle jo klant te helpen dy út. Getting oerienkomst betiid betsjut jo klant ferstiet dy senario en seit “”ja, dat is wat wy wolle.”” Brûke gefallen binne in grutte manier om derfoar te soargjen dat wat jo binne it bouwen is echt wat de klant wol, want se lit de akteurs, it brûken gefallen, en de relaasjes tusken harren.
Figuer 5: Brûk gefal diagram
Sa hawwe wy in grut skema dat graphically sjen my wat? It antwurd is ienfâldich â € “”it is in grutte skema dat jout in goed oersjoch fan it systeem. It lit sjen wat is bûten it systeem (toanielspilers) en de funksjonaliteit dat it systeem moat soargje (gebrûk gefallen). As der in legaat systeem jo moatte nimmen yn oanmerking, hjir is dêr’t jo omgean mei it. Twingt my om te wurkjen mei dizze soarten Schnittstellen hiel ier yn it projekt betsjut dat ik sil net wurde konfrontearre mei it foarútsjoch fan wachtsjen oant taalkodearjen start út te finen hoe’t ik om te praten mei dy swarte doaze, dat ik kin net feroarje .
Ien mear ding jo moatte witte oer gebrûk gefallen is it brûken gefal realisaasje. Dit is de “”hoe”” fan it brûken saak. It is meastal in amer dy’t befettet trije ferskillende soarten diagrammenStencils: folchoarder diagrammenStencils, gearwurking diagrammenStencils, en in klasse figuer dat wy neame in sicht fan dielnimmende klassen. Brûk gefal realizations binne yn prinsipe in manier fan groepearjen tegearre in tal keunstfoarwerpen oangeande it ûntwerp fan in gebrûk saak.
sequence diagrammenName
Sequence diagrammenStencils litte foarwerp ynteraksjes ynrjochte yn in tiid folchoarder. Ik kin gebrûk meitsje fan de stream fan eveneminten te bepalen hokker objekten en ynteraksjes ik sil moatte reach de funksjonaliteit oantsjutte troch de stream fan eveneminten.
Figuer 6: Sequence diagram
Figuer 6 lit sjen hoe’t in studint mei súkses rekket tafoege oan in kursus. De studint (lit syn neame him Joe) follet yn guon ynformaasje en yntsjinnet de foarm. De foarm dan praat oan de manager en seit “”add Joe nei Math 101.”” De manager fertelt Math 101 dat it hat te foegjen in studint. Math 101 seit ta Seksje 1 “”binne jo iepenje?”” Yn dit gefal, Paragraaf 1 antwurden dat se binne iepen, sa Math 101 fertelt diel 1 te foegjen dizze studint. Wer, sequence diagrammenStencils binne grutte ynstruminten yn it begjin, want se lit jo en jo klant stap-troch-stap wat hat te happen.
Ut in analyze punt fan each, ik haw fûn oer de jierren dat folchoarder diagrammenStencils binne tige machtich yn helpen my ride easken; benammen easken dy’t binne dreech te finen. Meidogger ynterface easken, bygelyks, binne berucht om’t dy altyd lykje te krijen easken dy’t krekt net testable. In mienskiplike UI eask as dit is “”dit systeem scil wêze brûker-freonlik.”” Hoefolle fan dy hawwe mei in freonlik kompjûter? Ien fan de foardielen fan dy soarten skema is dat eltse line komt út in akteur dy’t stiet foar in persoan, fertelt jo dat wat yn jo UI hat te bieden in feardigens nedich troch dy persoan. Yn oare wurden, kinne jo gebrûk meitsje fan sequence diagrammenStencils te riden út testable brûker ynterface easken.
Sequence diagrammenStencils binne, dêrom, goed foar sjocht wat der op, foar ride út easken, en foar wurkjen mei klanten. Dat meastentiids liedt ta de fraach, al, fan hoefolle hawwe jo nedich om meitsje? Myn antwurd is, “”oant jo dogge genôch.”” Jo binne der te finen út as jo dwaan sequence skema dat jo berikke in punt dêr’t jo binne gjin finen gjin nije foarwerpen, net fine gjin nije berjochten, en dat jo binne typen deselde saak oer en oer. Yn it foarbyld fan Joe oansluting Math 101, wy leare dat it proses soe wêze it itselde oft Joe woe om mei te dwaan Skiednis 101. Sa, regel fan thumb, dwaan in sequence diagram foar alle basis stream fan alle gebrûk saak. Doch in folchoarder diagram foar hege-nivo, risikofolle senario, en dat moat genôch. Dat is hoefolle sequence diagrammenStencils ik dwaan.
to remember hjir, is dat in gearwurking diagram is krekt in oare werjefte fan in senario en jo kinne gean hinne en wer tusken folchoarder diagrammenStencils en gearwurking skema om de werjefte dy’t bêste yllustrearret jo punt.
Sa no en dan, do miskien hearre de wurden “”ynteraksje diagrammenStencils.”” Soms minsken sille kollektyf ferwize nei in gearwurking diagram en in folchoarder diagram as ynteraksje diagram.
class diagrammenName
In klasse is in samling fan objekten mei mienskiplike struktuer, mienskiplike gedrach, mienskiplike relaasjes, en mienskiplike semantics. Jo fine se troch it ûndersykjen fan de objekten yn folchoarder en gearwurking skema ‘, en se binne fertsjintwurdige yn de UML as in rjochthoeke mei trije compartments.
Figure 8: Lessen
De earste koffer jout de klasse namme, de twadde toant syn struktuer (attributen), en de tredde toant syn gedrach (operaasjes). Dy compartments kinne wurde ûnderdrukt, lykwols, sadat jo sjen kinne krekt de namme, mar de namme en de attributen, of alle trije. Ien ding jo moatte ek witte is, dat it is wichtich, doe’t beneame klassen, te brûken de wurdskat fan it domein en kies in standert. Foar dit eksimplaar, myn lessen binne al singular Wurden yn it dy’t begjinne mei in haadletter. Jo kinne kieze te dwaan dat oars, en dat makket neat út. Wat docht saak is dat foar jo projekt jo helje in standert en stick mei it sa dat alles is konsekwint oer it projekt.
Klasse diagrammenName sjen litte jo it statyske karakter fan jo systeem. Dy skema ‘litte it bestean fan stannen en harren relaasjes yn it logysk werjefte fan in systeem. Jo hawwe in soad klasse diagrammenStencils yn in model.
De UML modellering eleminten fûn yn klasse diagrammenStencils binne:
Klassen en harren struktuer en gedrach.
Feriening, aggregation, ôfhinklikheid, en erfskip relaasjes.
Mannichfâldichheid en navigaasje yndikatoaren
Role nammen.
Nim efkes de tiid om Figure 9. Dizze diagram toant operaasjes (gedrach): wat in foarwerp yn dy klasse kin dwaan. Ik fyn myn operaasjes troch nei myn ynteraksjes diagrammenStencils.
Figuer 9: Operations
Hjir bin ik sei dat ik nedich te kinnen freegje de registraasje behearder te heakjen in learling nei Math
101. Dat giet te fertale yn in operaasje neamd “”addCourse.””
De struktuer fan in klasse wurdt fertsjintwurdige troch syn attributen. Dus hoe fyn ik myn attributen? Troch praten nei domein saakkundigen. By it sykjen om myn easken. Yn myn foarbyld, ik lear dat elke kursus oanbod hat in tal, in lokaasje, en in tiid. Dit fertaalt út nei trije attributen.
klassen. (Fertsjintwurdige yn de UML as in line ferbinen de besibbe klassen mei in diamant neist de klasse dy’t de hiele.)
â € ¢ Dependency â € “”in swakker foarm hjir de relaasje tusken in kliïnt en in leveransier dêr’t de klant hat gjin semantyske kennis fan de leveransier. In ôfhinklikens seit “”ik nedich jimme tsjinsten, mar ik wit net, dat jo bestean.”” (Fertsjintwurdige yn de UML as gie stees line wiist út de kliïnt oan de leveransier.)
Te finen relaasjes, ris wer, ik gean werom nei myn sequence diagram. As twa foarwerpen moatte “”prate””, der moat in middel om te dwaan sa (i.e., in ferhâlding tusken harren klassen).
Ik typysk start út en meitsje alles in feriening. As ik dogge mear analyze, ik soe fyn ik ha in aggregation omdat ik te moatte nimme soarch fan in âlder-bern relaasje. Doe’t ik yn ‘e ûntwerp faze, ik fyn út dat ik miskien net nedich in feriening omdat ien oars giet it barre dat foarwerp yn ien fan myn metoaden â € “”dus ik meitsje dat in ôfhinklikheid.
Figuer 11: Relationships
Yn Figure 11 jo sjogge dizze relaasjes. As feriening seit de heechlearaar kin praten nei de Course offer en de Kursus Marienheide kin prate nei de Professor. Berjochten kinne wurde inisjearre en gegevens kinne streame út elke rjochting. Aggregation wurdt sjen litten troch it hawwen fan de diamant nei de hiele â € “”yn dit gefal in Kursus bestiet út Course oanbod. De reden foar dizze aggregation soe wêze te fertellen myn ûntwikkelers dat as se ôf te kommen fan dit Course, se sille nei alle gedachten hawwe te dwaan wat bysûnders mei it Course bringe. Ofhinklikens wurde toand as gie stees line. It is sizzende dat de registraasje manager hinget op de Schedule algoritme te dwaan wat. De Schedule Algoritme is of in parameter oan ien fan ‘e metoaden of wurdt ferklearre lokaal troch ien fan de Metoaden fan de Registraasje Manager.
Mannichfâldichheid en Navigaasje
Mannichfâld definiearret hoefolle foarwerpen meidwaan oan in relaasje. It is it oantal eksemplaren fan ien klasse yn ferbân mei ien eksimplaar fan ‘e oare klasse. Foar eltse feriening en aggregation, binne der twa mannichfâld besluten om: ien foar eltse ein fan ‘e relaasje. Mannichfâld wurdt fertsjintwurdige as in oantal en in * wurdt brûkt om te fertsjintwurdigjen in mannichfâldichheid fan in protte.
Figuer 12: mannichfâld en navigaasje
Ien heechlearaar Objekt is yn ferbân mei nul-nei-fjouwer Kursus Marienheide Objects. Ien Kursus oanbieden Objekt is yn ferbân mei presys ien Heechlearaar Objekt. Ik brûk dit te sjen op en soargje dat dit hantearret myn easken. Kin ik in Course Marienheide en wurde team-leard troch in stel fan professors? Nee, want dit seit Ik kin allinne ha ien heechlearaar. Kin ik in heechlearaar en wêze op sabbatical? Ja, want dit seit ik ha in nul mooglik fansels lading. Ik brûk mannichfâld hiel faak te helpen my begjinne fêstlizzen en it útfieren fan myn bedriuw regels. As jo hawwe, bygelyks, in bedriuw regel dy’t seit jo moatte op syn minst 3 learlingen en net mear as 10 foar in kursus te wurde oanbean yn in semester, dy mearfâldichheid oantallen sis my Ik haw opnaam dat bedriuw regel yn dit plan.
Navigaasje wurdt sjen litten troch in pylk, en alhoewol’t ferieningen en aggregations binne bi-richtingskipper standert, it is faak winsklik te beheinen navigaasje nei ien rjochting. Doe’t navigaasje wurdt beheind, in arrowhead wurdt tafoege oan te jaan de navigaasjehelpmiddel rjochting. Ien fan ‘e dingen ik dwaan yn de analyze en design fazen is sjen wat ik wol te wêzen uni-richtingskipper. Troch de pylk yn dit diagram, ik sis dat de Registraasje Manager kin stjoere in berjocht oan de Koers, omdat it wit it Koers bestiet. Mar de Kursus hat gjin idee dat de Registraasje Manager bestiet, sadat de Kursus kin net initiate in berjocht. No gegevens kinne flow tusken harren; bygelyks de Registraasje Manager kin freegje de Kursus as it iepen en de Kursus kin sizze dat it is. Mar allinne de Registraasje Manager kin begjinne dat petear.
Fansels it doel hjir is om safolle pylken as kinne jo troch de tiid dy’t jo ha klear ûntwerpen, want it is in folle makliker systeem te behâlden Inheritance wurdt toand mei in trijehoek. Dat docht bliken dat de heechlearaar is in Registraasje Meidogger, as is it Student. No, in wurd fan warskôging. Erfskip is nuttich, lykwols, it doel is net te brûken safolle erfdiel as jo systeem sil tastean. Ik ha sjoen wat echt brutal systemen dêr’t se hie erfdiel 17-nivo djip. As se feroare ien ding, it waard in ramp. Sa de regel fan thumb is te brûken erfskip allinne as jo wier dwaan hawwe in erfskip situaasje.
State Transition diagrammenName
In steat oergong diagram toant it libben skiednis fan in opjûne klasse. It toant de foarfallen dy’t ta in oergong fan de iene steat nei de oare, en de aksjes dy’t resultearje út in steat feroaring.
Figuer 14: State oergong diagram
Ik brûk steat oergong diagrammenStencils foar objekt klassen dy’t typysk hawwe in soad fan de dynamyske gedrach. De knop is op: â € | de knop is off; Ik bin net te dwaan in steat chart foar it. Mar objekt klassen dy’t hawwe in soad fan dynamyske gedrach, ik bin nei alle gedachten gean om te sjen yn de steaten fan de foarwerpen.
Ik begjinne troch hjir in steat, dat is in ôfrûne trijehoek. Ik kin hawwe start steaten, en ik kin hawwe stop steaten, dy’t toand as bollen eagen. Ik kin ek hawwe oergongen tusken steaten, of wacht transysjes (dingen dy’t barre as allinne as in betingst is wier), of dingen dy’t barre as ik bin yn ‘e steat. Ik sjoch op dit diagram en sjogge de steat oergong diagram foar in kursus oanbod. It begjint yn it inisjalisaasje steat, en ik bliuw yn dat steat oant krij ik in “”add studint”” berjocht. Doe’t ik krij dat berjocht, ik set myn greve fan studint oan nul en ik oergong nei it Iepen steat. Jo sille sjen yn figuer 14 dat ik haw in yngong, en de reden wêrom’t it der is, dat ik haw twa manieren fan hieltyd yn dy steat. It seit dat gjin saak hoe’t jimme komme yn ‘e steat, Ik wol dy om registrearje de studint. Doe’t ik út dy steat, de greve feroarings te hâlden folgjen fan it tal studinten yn ‘e rin. Ik kin hâld it tafoegjen fan learlingen oant ik nei 10, en dan ik gean nei de Close steat. Sadree’t de kursus is definityf fêststeld, ik oergong nei it stop steat. Gjin saak dêr’t ik bin dan, as ik krij de Ofbrekke Event oergong, ik warskôgje myn studinten en dan oergong nei it stop steat.
Foar objekt klassen dy’t hawwe in soad fan dynamyske gedrach, it is goed de muoite wurdich om te dwaan in steat diagram om in stâle op alles dat hat te happen. Freegje dysels wat der bard as ik in berjocht? Wat ik dwaan as ik krij it berjocht? Wat berjochten nei Ik haw te stjoeren? In soad fan dy berjochten wurde operaasjes fan it foarwerp klasse, lykas yn dit foarbyld dêr’t in learling is in operaasje. In soad fan dizze aksjes, lykas it ynstellen fan de greve, incrementing de greve, kontrolearjen de greve, dy alle wurden privee operaasjes fan dat bysûndere foarwerp klasse en in steat diagram is dêr’t ik sjoch dat.
Hoe wolle jo witte oft jo in dynamyske foarwerp klasse? Ris wer, gean werom nei de folchoarder diagrammenStencils. As jo in foarwerp klasse, dat is op in soad folchoarder skema ‘en it wurdt en it ferstjoeren fan in soad fan berjochten, dat is in goede oantsjutting is it in frij dynamyske foarwerp klasse en dat moat nei alle gedachten hawwe in steat chart foar it. Ek foar aggregations, dêr’t jo de hiele fan syn dielen, ik doch in steat chart foar alle aggregate gehiel. Ik doch dat meast omdat dat aggregate gehiel is faak ferantwurdlik foar it behear fan de messaging, dat makket it dynamysk.
komponint diagrammenStencils
Fansels gjin systeem kin wurde boud sûnder rekken hâldend mei de fysike wrâld. Dat is wêr’t komponint diagrammenStencils komme yn. Se wurde brûkt om yllustrearje de organisaasjes en Ofhinklikens ûnder software ûnderdielen, ynklusyf boarne koade ûnderdielen, rinne tiid komponinten, of in útfierber komponint. Ûnderdielen binne shows as in grut rjochthoeke mei twa lytsere rjochthoeken oan ‘e kant, as sjoen yn figuer 15.
Figuer 15: Components
Dy rûne dingen fertsjintwurdigje Schnittstellen (faak neamd lollipop notaasje). Yn dit gefal, se sjen litte dat de Register.exe is ôfhinklik op Schnittstellen oan sawol de Course.dll en de People.dll. Dat betsjut as dizze Schnittstellen feroarje, dan sil effekt de Register.exe. Ik wit dat der is dizze regel as jo binne it bouwen Schnittstellen dy’t seit: “”Jo sille net feroarje de ynterface.”” Mar hat ien eins wurkje wêr’t dat regel is ôftwongen? Dizze diagram fertelt ús wat Schnittstellen wurde brûkt troch wat programmatriemmen binne aktyf op myn Prozessoren.
Figuer 16: Deployment diagram
útwreidzjen UML
It lêste wat ik wol in soad oer it UML is dat it kin ferlingd wurde. Doe’t hja bouden it UML, se tige wiis besefte dat der wie gjin wei se koe meitsje in skriuwwize dy’t koe haegje al fan ‘e minsken al fan de tiid. Hja joech ús it konsept fan in stereotype. In stereotype seit ik kin nimme in basis modellewurk elemint en jou it mear betsjutting. Stereotypen kinne brûkt wurde om te klassifisearjen en útwreidzje ferienings, erfskip relaasjes, klassen, en komponinten.
Figuer 17: Web stereotype foarbyld
Figuer 17 toant it skema fan ús Web stereotypen. In webside meastal hat stuff dat rint op de tsjinner en guod dat rint op ‘e klant. As jo it bouwen fan Web-basearre tapassingen, wat rint op ‘e klant en de tsjinner is fan libbensbelang. Sa hawwe wy in hiele set fan stereotypen dy’t sjen litte dat. De lytse tsjillen fertsjintwurdigje dingen dy’t rinne op de tsjinner. Sa gewoan by it sykjen op dit iene diagram kin ik sjen wat rint op de tsjinner, wat rint op de kliïnt, en wat saaklike foarwerpen se hawwe te krijen mei.

“——————————————————————————————————————————————————

Tradución Apoio: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”A UML é a linguaxe estándar para especificar, visualizar, construír e documentar todos os artefactos dun sistema de software.””
Diagramas de actividade
O sitio lóxico para comezar a andar a través de algúns dos diagramas UML é mirando para os diagramas de actividades.
Figura 2: Diagrama Actividade
Os diagramas de actividades mostran o fluxo de control. Como ilustrado na Figura 2, podes ver as actividades representados como rectángulos redondeados. As actividades son normalmente estados de acción â € “”afirma que a transición automática ao seguinte estado despois de que a acción é rematado. A cuberto círculo representa o inicio do diagrama de actividade â € “”onde o fluxo de control comeza. Transicións mostradas como frechas mostran como se move de actividade para actividade. barras de sincronización mostran como actividades acontecen en paralelo. Podo gardar unha transición que di: “”Eu quero que vaia a esta actividade só se esa condición sexa verdadeira,”” e podo amosar-lle onde se detén. Agora, se vostede é de certa idade, probablemente vai mirar para este diagrama de actividades e pensar: “”hmm â € | que se parece un fluxogramas.”” E iso é o que é, só que eu non estou facendo isto para abaixo ao nivel da programación. Normalmente, eu uso un diagrama de actividades moi cedo no meu proceso de análise e deseño para mostrar o fluxo de traballo de empresas. Eu tamén vou usalos para amosar onde cada un dos meus casos de uso pode estar nunha actividade para ilustrar o caso de uso ten que acontecer. Eu tamén uso diagramas de actividades para mostrar como as cousas flúen entre os meus casos de uso.
Pero unha das grandes cousas sobre a UML é a súa versatilidade. Entón, mentres eu usar diagramas de actividade no inicio do ciclo de vida, outras persoas poden usalos nunha fase diferente. Vin xente usar a actividade Diagramas para abaixo no nivel de deseño, onde eles tiñan un conxunto moi complicado de algoritmos para unha determinada clase. E moita xente usalos para amosar o fluxo entre os métodos dunha clase.
o sistema. Actores son representados como figuras da vara.
Figura 4: Actores
O exemplo que eu traballei para esta introdución á UML é un modelo pequeno dun sistema de inscrición do curso. Polo tanto, neste exemplo, o primeiro que eu faría cando se inicia o meu proceso de análise é preguntar: “”quen vai a interactuar con este sistema?””
Para o modelo de inscrición do curso, eu teño un registrador, un profesor e un estudante. Eu tamén teño un sistema de facturación externo. Este sistema de facturación tamén se cualifica como un actor. (Véxase, un axente non ten que ser un unha persoa € “”é algo que interactúa co sistema, pero está fóra do sistema.)
Un caso de uso é unha secuencia de operacións relacionadas realizadas por un actor no sistema nun diálogo. Ou, para poñelas en inglés, un caso de uso é unha peza de funcionalidade. E aquí está a clave: non é un módulo de software â € “”é algo que ofrece o valor para o actor.
Os casos de uso son presentados como ovais, ea forma máis fácil de atopalos é ollar para cada un dos seus actores e preguntar por que eles queren usar o sistema. No meu caso, o meu rexistro manterá o currículo, o meu profesor vai pedir unha lista, meu alumno mantén o programa, eo meu sistema de facturación recibe a información de facturación. Entón eu crear os meus casos de uso de miralo desde o punto de vista do cliente e preguntar, “”por iso, o actor sistema señor, por que quere usar o sistema? Cal é o valor que este sistema ofrece a vostede?””
O seguinte paso, xa que identificou como os seus actores estarán interactuar co sistema, é facer documentar os seus casos de uso. Cada caso de uso debe ser documentado co fluxo dos acontecementos, e iso está feito desde o punto de vista do actor. Debe detallar o que o sistema debe proporcionar ao actor cando o caso de uso é executado. Normalmente vai amosar cousas como o caso de uso comeza e remata. Que cousas é que isto caso de uso ten que facer? Terá o fluxo normal de eventos (o que eu chamo de “”días felices”” escenario), onde todo funciona. Entón terá o fluxo anormal de eventos, o escenario de “”día de choiva””. Que pasa cando o sistema non funciona? Descubrir, documentando o meu fluxo de eventos que sempre comezan co escenario de días felices.
Tomé-se como exemplo, camiñando ata un cadro automático. Andar ata o cadro electrónico e insira a tarxeta. El pide para o seu número PIN. Entrar nel, e élle preguntado o que desexa facer. Vostede di “”Eu quero un diñeiro.”” El pregunta onde o diñeiro debe ser tirado. Diga a el para levala a súa conta corrente. El pregunta canto. Di US $ 100,00. Entón a maxia acontece â € | dálle US $ 100,00. A continuación, el pregunta se quere outra transacción. Dicir non. Dálle a súa tarxeta de volta, dálle un recibo, ea transacción é longo. Ese é o escenario día feliz.
Segundo escenario. Ir ata o ATM, inserir a tarxeta e escribir o PIN. A ATM di que é o PIN incorrecto. Escribe o seu número de novo. Unha vez dixo que o PIN incorrecto. Vostede No meu exemplo de rexistro de curso, por exemplo, podes ver que hai unha morea de “”se X entón Y”” fluxos de traballo. É aí que quere que o seu cliente para axudar. Obtendo acordo significa inicio do seu cliente entende estes escenarios e di “”Si, iso é o que queremos.”” Os casos de uso son unha boa forma de garantir que o que está a construír é realmente o que o cliente quere, porque mostran os actores, os casos de uso, e as relacións entre eles.
Figura 5: diagrama de caso de uso
Polo tanto, temos unha gran diagrama que graficamente me o que mostra? A resposta é sinxela â € “”é un gran diagrama que mostra unha boa visión xeral do sistema. Amosa que está fóra do sistema (axentes) e función de que o sistema debe proporcionar (casos de uso). Se hai un sistema legado que cómpre ter en conta, aquí é onde se encarga de iso. Obrigando-me a traballar con estes tipos de interfaces moi no inicio do proxecto significa que eu non vou ser afrontar a perspectiva de agardar a que a codificación comeza a descubrir como vou falar con esa caixa negra que eu non podo mudar .
Só unha cousa que ten que saber sobre casos de uso é a realización de casos de uso. Este é o “”como”” do caso de uso. É xeralmente un balde que contén tres tipos de diagramas: diagramas de secuencia, diagramas de colaboración e un diagrama de clases que chamamos unha visión das clases participantes. Use realizacións de casos son, basicamente, un xeito de agrupar unha serie de artefactos relacionados co deseño dun caso de uso.
Diagramas de secuencia
diagramas de secuencia mostran interaccións de obxectos organizados nunha secuencia de tempo. Eu podería usar o fluxo de eventos para determinar cales son os obxectos e as interaccións que precisa para realizar a función especificada polo fluxo de eventos.
Figura 6: Diagrama de secuencia
A Figura 6 mostra como un estudante con éxito se engade a un curso. O estudante (imos chamalo de Joe) enche unha información e envía o formulario. O formulario, a continuación, fala co director e di “”engadir Joe para Math 101.”” O director di Math 101 que ten que engadir un alumno. Matemáticas 101 di a Sección 1 “”é abrir?”” Neste caso, Sección 1 respostas que están abertos, polo Math 101 di sección 1 para engadir este estudante. Unha vez máis, diagramas de secuencia son óptimas ferramentas no inicio porque demostran que vostede eo seu cliente paso a paso o que ten que pasar.
Dun punto de vista de análise, atopei ao longo dos anos que os diagramas de secuencia son moi poderosos en axudar-me dirixir requisitos; especialmente requisitos que son difíciles de atopar. requisitos de interface de usuario, por exemplo, son notorios porque parece sempre chegar requisitos que non só testável. Un requisito de interface de usuario común, como este é “”este sistema debe ser fácil de usar.”” Como moitos de vostedes xa atopou un ordenador agradable? Un dos beneficios deste tipo de diagramas é que cada liña vindo dun actor que representa unha persoa, dille que algo na súa interface de usuario ten que proporcionar a capacidade necesaria por esa persoa. Noutras palabras, pode utilizar diagramas de secuencia para expulsar os requisitos de interface de usuario examinabades.
diagramas de secuencia son, polo tanto, bo para mostrar o que está pasando, para a condución de requisitos, e para traballar cos clientes. Que normalmente leva á cuestión, con todo, de cantos precisa crear? A miña resposta é, “”ata que facer o suficiente.”” Vai descubrir cando fai diagramas de secuencia que chegar a un punto en que non está atopando os novos obxectos, non atopando calquera mensaxes, e que está escribindo o mesmo unha e outra. No exemplo de Joe unirse matemáticas 101, aprenden que o proceso sería o mesmo se Joe quería unirse a Historia 101. Así, por regra xeral, facer un diagrama de secuencia para cada fluxo básico de todos os casos de uso. Fai un diagrama de secuencia para de alto nivel, os escenarios de risco, e que debe ser suficiente. É así que moitos diagramas de secuencia que fago.
a lembrar aquí é que un diagrama de colaboración é só unha visión diferente dun escenario e pode ir e volver entre diagramas de secuencia e diagramas de colaboración para a vista que mellor ilustra o seu punto.
Ás veces, é posible escoitar a frase “”diagramas de interacción.”” Ás veces, as persoas van referirse colectivamente a un diagrama de colaboración e un diagrama de secuencia como un diagrama de interacción.
Diagramas de Clases
Unha clase é unha colección de obxectos con estrutura común, comportamento común, as relacións comúns, e semántica comúns. Atopalos a través da análise dos obxectos en diagramas de secuencia e de colaboración, e son representados na UML como un rectángulo con tres compartimentos.
Figura 8: Clases
O primeiro recinto mostra o nome da clase, o segundo mostra a súa estrutura (atributos), eo terceiro mostra o seu comportamento (operacións). Estes compartimentos poden ser suprimidas, con todo, de xeito que se pode ver só o nome, só o nome e os atributos, ou os tres. Unha cousa que tamén debe saber é que é importante, ao nomear as clases, para usar o vocabulario do dominio e escoller un estándar. Para este exemplo, as miñas clases son todos os substantivos singulares que comezan cunha letra maiúscula. Pode optar por facelo de forma distinta, e iso non importa. O importante é que, antes do seu proxecto que escoller un estándar e ir con ela para que todo sexa consistente en todo o proxecto.
Clase Diagramas de amosar-lle a natureza estática do seu sistema. Estes diagramas mostran a existencia de clases e as súas relacións na visión lóxica dun sistema. Terá moitas diagramas de clases dun modelo.
Os elementos de modelaxe UML atopadas diagramas de clase inclúen:
Clases ea súa estrutura e comportamento.
relacións de asociación, agregación, dependencia, e herdanza.
indicadores de multiplicidade e de navegación
nomes de función.
Bótalle un ollo á Figura 9. Este diagrama mostra operacións (comportamento): o que un obxecto desta clase pode facer. Creo que as miñas tarefas, mirando para os meus diagramas de interaccións.
Figura 9: Operacións
Aquí eu estou dicindo que eu teño poder pedir o director de rexistro para engadir un alumno a matemática
101. Isto vai traducirse nunha operación chamada “”addCourse.””
A estrutura dunha clase é representada polos seus atributos. Entón, como podo atopar os meus atributos? Ao falar con expertos do ámbito. Ao mirar para as miñas necesidades. No meu exemplo, aprendo que cada oferta de curso ten un número, un lugar e unha hora. Isto tradúcese a tres atributos.
clases. (Representada na UML como unha liña conectando as clases relacionadas cun diamante á beira da clase que representa o todo.)
â € ¢ Dependencia â € “”unha forma máis débil que mostra a relación entre un cliente e un provedor, onde o cliente non ten coñecemento semántico do provedor. Unha dependencia di “”Eu teño os seus servizos, pero eu non sei que existe.”” (Representados en UML como unha liña a trazos que apunta a partir do cliente para o provedor).
Para atopar relacións, unha vez máis, eu vou volver para o meu diagrama de secuencia. Dous obxectos que “”falar””, ten que haber un medio para facelo (isto é, unha relación entre as súas clases).
Eu normalmente comezar e facer todo dunha asociación. Como eu estou facendo unha análise máis aprofundada, eu podería atopar Teño unha agregación porque eu vou ter que coidar dunha relación pai-fillo. Cando entrar na fase de proxecto, eu descubrir que eu non pode ter unha asociación porque alguén vai pasar este obxecto nun dos meus métodos â € “”entón eu o fan unha dependencia.
Figura 11: Relacións
Na Figura 11 ve esas relacións. Como asociación di que o profesor pode falar coa oferta de curso, ea oferta de curso pode falar co profesor. As mensaxes poden ser iniciadas e os datos poden fluír en calquera dirección. Agregación aparece por ter o diamante para todo o â € “”, neste caso un curso consta de ofertas de cursos. A razón para esta agregación sería dicir aos meus colaboradores que si se librar deste curso, probablemente vai ter que facer algo especial coas ofertas de cursos. Dependencias móstranse como unha liña a trazos. É dicir que o director de rexistro depende do algoritmo de Programación para facer algo. O algoritmo Marcar é un parámetro a un dos métodos ou é declarado local por un dos métodos de Rexistro do xestor.
Multiplicidade e Navegación
Multiplicidade define cantos obxectos participar dunha relación. É o número de instancias dunha clase relacionada dunha instancia da outra clase. Para cada asociación e agregación, existen dúas decisións multiplicidade de facer: un para cada extremo da relación. A multiplicidade é representado como un número e un * úsase para representar unha multiplicidade de moitos.
Figura 12: Multiplicidade e navegación
Un obxecto Profesor está relacionado a cero a catro obxectos oferta de curso. Un Curso Ofrecendo obxecto está relacionado con exactamente un obxecto Profesor. Eu uso iso para ollar e garantir que este trata sobre as miñas necesidades. Podo ser unha oferta de curso e ser team-ensino por un grupo de profesores? Non, porque esta di que só pode ter un profesor. Podo ser un profesor e estar en sabático? Si, porque esta di que eu teño un cero como posible carga horaria. Eu uso multiplicidade miúdo para me axudar a comezar a capturar e implementar as miñas regras de negocio. Se ten, por exemplo, unha regra de negocio que di que ten que ter un mínimo de 3 alumnos e non máis de 10 para un curso a ser ofrecido nun semestre, estas cifras multiplicidade me dicir que eu xa incorporou esta regra de negocio para este plan.
A navegación é mostrado por unha frecha, ea pesar de asociacións e agregacións son bidirecionais por defecto, é moitas veces desexable para restrinxir a navegación a unha dirección. Cando a navegación é restrinxido, unha punta de frecha engádese para indicar a dirección de navegación. Unha das cousas que fago durante as fases de análise e deseño é mirar para o que quero ser uni-direccional. Ao poñer a frecha neste diagrama, digo que o xestor de Rexistro pode enviar unha mensaxe ao Curso porque sabe existe o Curso. Pero o curso non ten idea de que existe o Director de Rexistro, de xeito que o curso non pode comezar unha mensaxe. Agora, os datos poden fluír entre eles; por exemplo, o Xestor de Rexistro pode pedir o Curso se está aberto eo curso pode dicir que é. Pero só o Director de Rexistro pode comezar esta conversa.
Obviamente, o obxectivo aquí é conseguir o máximo de frechas, como pode no momento en que termine de proxectar, porque é un sistema moito máis doado de manter Herdanza aparece cun triángulo. Isto amosa que o profesor é un usuario de Rexistro, como é o Student. Agora, unha palabra de advertencia. A herdanza é útil, con todo, o obxectivo non é por tanto herdanza como sistema permitir. Vin algúns sistemas realmente brutais onde tiveron de herdanza de 17 niveis de profundidade. Se cambiaron algo, tornouse un desastre. Polo tanto, a regra de ouro é usar a herdanza só cando realmente ten unha situación de herdanza.
Diagramas de transición de estado
Un diagrama de transición de estado mostra a historia de vida dunha determinada clase. Amosa os eventos que causan unha transición dun estado a outro, e as accións que resultan de un cambio de estado.
Figura 14: Diagrama de transición de estado
Eu uso diagramas de transición de estado para clases de obxectos que normalmente teñen unha morea de comportamento dinámico. O botón está € â | botón está desactivado; Non vou facer un gráfico de estado para el. Pero as clases de obxectos que teñen unha morea de comportamento dinámico, eu probablemente vou ter que mirar para os estados dos obxectos.
I comezar por amosar un estado, que é un triángulo redondeado. I pode estar de inicio, e podo ter estados de parada, que son mostrados como ollos de touros. Tamén pode ter transicións entre estados ou transicións de garda (cousas que acontecen cando só cando unha condición é certa), ou cousas que acontecen cando estou no interior do Estado. I mirar para este diagrama e consulte o diagrama de transición de estados para unha oferta de curso. Comeza no estado de arranque, e eu ir nese estado ata que eu recibín unha mensaxe de “”add estudante””. Cando chegar esta mensaxe, eu definir a miña conta de estudante a cero e eu transición para o estado aberto. Vai ver na Figura 14 que eu teño unha entrada, ea razón pola que está aí é que eu teño dous xeitos de entrar nese estado. Di que non importa como vén para o estado, quero que rexistrar o alumno. Cando saír dese estado, os cambios da conta de manter o control do número de alumnos do curso. Podo seguir engadir estudantes ata chegar a 10, e despois vou para o estado en Pechar. Xa que o curso é finalizado, eu transición para o estado de parada. Non importa onde eu son, entón, se eu comezar a transición Desfacer Evento, eu notificar os meus alumnos e, a continuación, a transición para o estado de parada.
Para as clases de obxectos que teñen unha morea de comportamento dinámico, é así paga a pena facer un diagrama de estado para obter unha alza sobre todo o que ten que pasar. Pregunta a si mesmo o que ocorre cando recibo unha mensaxe? O que fago cando recibín a mensaxe? Que mensaxes que enviar? Moitas destas mensaxes fan a operacións da clase de obxecto, como neste exemplo onde engadir un alumno é unha operación. Moitas destas accións, como configurar a conta, incrementando a conta, alomenos a conta, todos estes fan a operacións privadas desta clase de obxecto particular e un diagrama de estado é onde eu vexo isto.
Como vostede sabe se ten unha clase de obxecto dinámico? Unha vez máis, volva para os diagramas de secuencia. Se vostede ten unha clase de obxecto que está en un monte de diagramas de secuencia e está quedando e enviar unha chea de mensaxes, que é unha boa indicación de que é unha clase de obxecto moi dinámica e probablemente debe ter un gráfico de estado para el. Tamén para agregacións, onde ten o conxunto das súas partes, fago un gráfico de estado para cada conxunto agregado. Fago isto sobre todo porque que todo agregada é moitas veces responsable da xestión de mensaxes, o que o fai dinámico.
Os diagramas de componentes
Claro que ningún sistema pode ser construída sen ter en conta o mundo físico. É aí que diagramas de componentes entrar. Son usados para ilustrar as organizacións e dependencias entre os compoñentes de software, incluíndo compoñentes de código fonte, os compoñentes tempo de execución, ou un compoñente executable. Os compoñentes aparecen como unha gran rectángulo con dous rectángulos menores no lado, como se pode ver na Figura 15.
Figura 15: Compoñentes
Aquelas cousas redondas representan interfaces (moitas veces chamado de notación Lollipop). Neste caso, mostran que a Register.exe é dependente de interfaces para ambos o Course.dll eo People.dll. Isto significa que se esas interfaces cambiar, iso terá impacto sobre o Register.exe. Sei que hai esta regra cando constrúe interfaces que di “”non debe cambiar a interface.”” Pero será que alguén realmente traballar onde esta regra aplícase? Este diagrama dinos que as interfaces son usados por que executable están sendo executados en meus procesadores.
Figura 16: Diagrama Implantación
estendéndose UML
A última cousa que quero salientar sobre a UML é que pode ser estendido. Cando construíron o UML, eles moi sabios entender que non había ningunha maneira que podería crear unha notación que pode compracer a todas as persoas o tempo. Entón eles nos deron o concepto dun estereotipo. Un estereotipo di que eu podo ter un elemento básico modelaxe e dar máis significado. Estereotipos poden ser usados para clasificar e estender asociacións, relacións de herdanza, clases e compoñentes.
Figura 17: Exemplo estereotipo web
A Figura 17 amosa o diagrama dos nosos estereotipos web. Unha páxina web normalmente ten cousas que se executa o servidor e outras cousas que se executa no cliente. Se constrúe aplicacións baseadas na web, o que está en execución no cliente eo servidor é de vital importancia. Polo tanto, temos un conxunto de estereotipos que mostran tanto. As pequenas rodas representan cousas que son executados no servidor. Entón, só de ollar para este diagrama que eu poida ver o que se executa o servidor, o que se executa no cliente, e que obxectos de negocio que teñen que tratar con eles.

“——————————————————————————————————————————————————

მხარდაჭერა თარგმანი: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”The UML არის სტანდარტული ენის სასურველი, ვიზუალურ, აშენებს და დოკუმენტირების ყველა ნიმუშებს პროგრამული სისტემა.””
აქტიურობა დიაგრამები
ლოგიკური დაიწყოს გავლით ზოგიერთი UML დიაგრამები არის შევხედავთ საქმიანობის დიაგრამები.
დიაგრამა 2: საქმიანობის სქემა
აქტიურობა დიაგრამებზე ნაჩვენებია ნაკადის კონტროლი. როგორც ნაჩვენებია ფიგურა 2, ხედავთ საქმიანობის წარმოდგენილია როგორც მომრგვალებული ოთხკუთხედს. საქმიანობა, როგორც წესი, მოქმედების ქვეყნების â € “”აცხადებს, რომ გარდამავალი ავტომატურად მომდევნო სახელმწიფოს ქმედება არის სრული. შევსებული წრე წარმოადგენს დაწყების საქმიანობის სქემა â € “”სადაც ნაკადის კონტროლი იწყება. Transitions ნაჩვენები როგორც ისრები ნახოთ, თუ როგორ გადაადგილება საქმიანობის საქმიანობაში. სინქრონიზაციის ბარები ნახოთ, თუ როგორ საქმიანობის მოხდეს პარალელურად. მე ვერ დაიცავს გარდამავალი, რომელიც ამბობს, “”მე მინდა წასვლა ამ საქმიანობაში, თუ ეს მდგომარეობა მართალია,”” და მე ვერ აჩვენებს, თუ სად ის შეწყვეტს. ახლა, თუ თქვენ გარკვეული ასაკის, თქვენ ალბათ შევხედოთ ამ საქმიანობის სქემა და ვფიქრობ, “”hmm â € | ჰგავს ნაკადის ჩარტში.”” და ეს არის ზუსტად ის, რაც არის, გარდა იმისა, რომ მე არ ვაკეთებთ ქვემოთ პროგრამირების დონეზე. როგორც წესი, გამოვიყენო საქმიანობის სქემა საკმაოდ დილით ჩემი ანალიზი და დიზაინი პროცესი, შოუ ბიზნესის workflow. მე ასევე მათი გამოყენება აჩვენებს, სადაც თითოეული ჩემი გამოყენების შემთხვევაში შეიძლება იყოს საქმიანობის ცხადყოფს, თუ რა გამოყენების შემთხვევაში უნდა მოხდეს. მე ასევე გამოიყენოთ საქმიანობის დიაგრამების ნახოთ, თუ როგორ შემოვა შორის ჩემი გამოყენების შემთხვევაში.
მაგრამ ერთი დიდი რამ UML მისი versatility. ასე რომ, მე გამოიყენოს საქმიანობის დიაგრამების დასაწყისში ციკლის, სხვები შეიძლება მათი გამოყენება სხვადასხვა ფაზაში მთლიანად. მე ვნახე ადამიანი გამოიყენებს საქმიანობის დიაგრამების ქვემოთ დიზაინი დონეზე, სადაც მათ ჰქონდათ ძალიან რთული კომპლექტი ალგორითმები კონკრეტული კლასის. და ბევრი ადამიანი გამოიყენებს მათ დავანახოთ ნაკადი მეთოდებს შორის კლასი.
სისტემა. მსახიობები წარმოდგენილია როგორც ჯოხი მოღვაწეები.
გრაფიკი 4: მსახიობები
მაგალითად, რომ ვმუშაობდი up for ეს შესავალი UML არის პატარა მოდელი, რა თქმა უნდა სარეგისტრაციო სისტემა. ასე რომ, ამ შემთხვევაში, პირველი, რაც მე ამის გაკეთება, როდესაც დაწყებული ჩემი ანალიზი პროცესი ვთხოვთ “”, რომელიც აპირებს ურთიერთქმედება ეს სისტემა?””
რა თქმა უნდა რეგისტრაციის მოდელი, მაქვს რეგისტრატორი, პროფესორი, და მოსწავლე. მე ასევე გარე საბილინგო სისტემის. ბილინგის სისტემა ასევე კვალიფიცირდება, როგორც მსახიობი. (იხილეთ, მსახიობი არ უნდა იყოს პირი â € “”ეს არაფერი, რომ ურთიერთქმედებს სისტემა, მაგრამ გარეთ არის სისტემა.)
გამოყენების შემთხვევაში არის თანმიმდევრობა დაკავშირებული ოპერაციების მსახიობი სისტემაში დიალოგი. და, იმისათვის, რომ ეს ინგლისურ, გამოყენების შემთხვევაში არის ბლოკი ფუნქცია. აქ არის გასაღები: ეს არ არის პროგრამული მოდული â € “”ეს არის ის, უზრუნველყოფს ღირებულება მსახიობი.
გამოყენების შემთხვევაში ნაჩვენებია როგორც ovals, და მარტივი გზა, რათა იპოვოს მათ შევხედოთ თითოეული თქვენი მსახიობები და ჰკითხეთ საკუთარ თავს, თუ რატომ გსურთ გამოიყენოთ სისტემა. ჩემს შემთხვევაში, ჩემი რეგისტრატორი შეინარჩუნებს სასწავლო გეგმა, ჩემი პროფესორი აპირებს მოითხოვოს მოშორებას, ჩემი სტუდენტი ინარჩუნებს გრაფიკი, და ჩემი დაანგარიშების სისტემა იღებს ბილინგის ინფორმაცია. ასე რომ შევქმნა ჩემი გამოყენების შემთხვევაში შევხედავთ მას მომხმარებელს თვალსაზრისით და ითხოვს, “”ასე რომ, ბატონო სისტემა მსახიობი, რატომ გსურთ გამოიყენოთ სისტემა? რა მნიშვნელობა აქვს ამ სისტემის უზრუნველყოფს თქვენ?””
შემდეგი ნაბიჯი, ერთხელ თქვენ განსაზღვრული, თუ როგორ თქვენი მსახიობები უნდა ინტერაქციაში სისტემით, do დოკუმენტურად თქვენი გამოყენების შემთხვევაში. თითოეული გამოყენების შემთხვევაში საჭიროებს დაზუსტებას მფლობელის დოკუმენტურად ნაკადის მოვლენები, და ეს კეთდება მსახიობის თვალსაზრისით. ეს უნდა დეტალურად რა უნდა უზრუნველყოს, რომ მსახიობი, როდესაც გამოყენების შემთხვევაში ხორციელდება. როგორც წესი, ეს გამოჩნდება, როგორიც გამოყენების შემთხვევაში იწყება და მთავრდება. რა რამ, რომ ჯერ გამოყენების შემთხვევაში უნდა გავაკეთოთ? თქვენ არ გაქვთ ნორმალური ნაკადის მოვლენები (რაც მე მოვუწოდებ “”ბედნიერი დღე”” სცენარი), სადაც ყველაფერი მუშაობს. მაშინ თქვენ მიიღებთ პათოლოგიური ნაკადის მოვლენები, “”წვიმიანი დღე”” სცენარი. რა ხდება, როდესაც სისტემა არ მუშაობს? მე ი დოკუმენტურად ჩემი ნაკადის მოვლენები, რომ მე ყოველთვის იწყება ბედნიერი დღეები სცენარი.
როგორც, მაგალითად, ფეხით მდე ავტომატური მთხრობელი მანქანა. ფეხით მდე ბანკომატში და ჩადეთ ბარათი. იგი ითხოვს თქვენი PIN ნომერი. გადიხარ, და სთხოვა, თუ რა სურს ამის გაკეთება. თქვენ ამბობთ, “”მე მინდა ფული.”” იგი სთხოვს, სადაც ფული უნდა იყოს აღებული. თქვენ გითხრათ, რომ მიიღოს ის თქვენს მიმდინარე ანგარიშზე. იგი სთხოვს რამდენად. თქვენ ამბობთ $ 100.00. მაშინ ჯადოსნური ხდება € | ეს გაძლევთ $ 100.00. მაშინ ეს სთხოვს თუ გსურთ სხვა გარიგება. თქვენ ამბობთ, არ არსებობს. ეს გაძლევთ თქვენი ბარათის უკან, გაძლევთ მიღების, და გარიგება დასრულდა. ეს არის ბედნიერი დღე სცენარი.
მეორე სცენარი. თქვენ ადით ბანკომატი, ჩადეთ ბარათი, და შეიყვანოთ თქვენი PIN. ბანკომატით გიჩვენებთ ეს არასწორი PIN. თქვენ შეიყვანოთ თქვენი ნომერი ერთხელ. ერთხელ თქვენ განუცხადა, რომ პინ არასწორია. თქვენ ჩემი, რა თქმა უნდა რეგისტრაციის მაგალითად, მაგალითად, თქვენ ხედავთ, რომ არსებობს ბევრი “”თუ X მაშინ Y”” workflows. სწორედ იქ, სადაც გსურთ თქვენი მომხმარებელს, რათა დაგეხმაროთ out. თანხმობის მისაღებად დასაწყისში ნიშნავს, რომ თქვენი მომხმარებელს ესმის ეს სცენარი და აცხადებს, რომ “”დიახ, ეს არის ის, რაც ჩვენ გვინდა.”” გამოყენების შემთხვევაში არის დიდი გზა, რათა უზრუნველყოს, რომ ის, რაც თქვენ მშენებლობის მართლაც რა მომხმარებელს სურს, იმიტომ, რომ ისინი მსახიობები, გამოყენების შემთხვევაში და ურთიერთობები, მათ შორის.
გრაფიკი 5: გამოიყენეთ შემთხვევაში სქემა
ასე რომ, ჩვენ გვაქვს დიდი სქემა, რომელიც გრაფიკულად აჩვენებს რა? პასუხი მარტივია â € “”ეს არის დიდი სქემა, რომელიც გვიჩვენებს კარგი მიმოხილვა სისტემა. ის გვიჩვენებს, თუ რა არის სისტემის გარეთ (მსახიობები) და ფუნქციონალური, რომ უნდა უზრუნველყოს (გამოყენების შემთხვევაში). თუ არ არის მემკვიდრეობა სისტემა თქვენ უნდა გაითვალისწინოს, აქ, სადაც თქვენ გაუმკლავდეთ მას. აიძულა ჩემთვის მუშაობა ამ ტიპის ინტერფეისი ძალიან ადრე პროექტის იმას ნიშნავს, რომ მე არ იქნება წინაშე პერსპექტივა ელოდება სანამ კოდირების იწყება გაერკვნენ, თუ როგორ მე ვაპირებ გაიგო, რომ შავი ყუთი რომ მე ვერ შეცვლის .
კიდევ ერთი რამ, რაც უნდა იცოდეთ გამოყენების შემთხვევაში არის გამოყენების შემთხვევაში რეალიზაციას. ეს არის “”როგორ”” გამოყენების შემთხვევაში. ეს, როგორც წესი bucket, რომელიც შეიცავს სამი სხვადასხვა ტიპის დიაგრამების: თანმიმდევრობით დიაგრამების, თანამშრომლობის დიაგრამების და კლასის გრაფიკაზე, რომ ჩვენ მოვუწოდებთ ხედი მონაწილე კლასები. გამოყენების შემთხვევაში რეალიზაცია ძირითადად გზა დაჯგუფება ერთად რაოდენობის ნიმუშებს, რომლებიც ეხება დიზაინის გამოყენების შემთხვევაში.
Sequence დიაგრამები
Sequence დიაგრამებზე ნაჩვენებია ობიექტის ურთიერთქმედების მოწყობილი დროს თანმიმდევრობით. შემიძლია ნაკადი მოვლენების განსაზღვროს, თუ რა ობიექტები და ურთიერთქმედების მე უნდა შეასრულოს ფუნქციონალური მიერ მითითებული ნაკადის მოვლენები.
გრაფიკი 6: Sequence სქემა
ფიგურა 6 გვიჩვენებს, თუ როგორ სტუდენტი წარმატებით ემატება რა თქმა უნდა. სტუდენტი (მოდით მას ჯო) ავსებს გარკვეული ინფორმაცია და წარუდგენს ფორმა. ფორმა შემდეგ საუბრობს მენეჯერი და აცხადებს, რომ “”დაამატოთ ჯო მათემატიკის 101.”” მენეჯერი ეუბნება მათემატიკის 101, რომ მას აქვს დაამატოთ სტუდენტი. მათემატიკის 101 ამბობს, რომ 1-ლი განყოფილება “”თქვენ გახსნას?”” ამ შემთხვევაში, ნაწილი 1 პასუხობს, რომ ისინი ღია, ისე მათემატიკის 101 ეუბნება განყოფილება 1 დაამატოთ ეს სტუდენტი. ისევ და ისევ, თანმიმდევრობით დიაგრამების დიდი ინსტრუმენტები დასაწყისში იმიტომ, რომ ისინი თქვენ და თქვენი ნაბიჯ ნაბიჯ, თუ რა უნდა მოხდეს.
საწყისი ანალიზი თვალსაზრისით, მე ი წლების განმავლობაში, რომ თანმიმდევრობით დიაგრამების ძალიან ძლიერი ეხმარება me მანქანა მოთხოვნები; განსაკუთრებით მოთხოვნები, რომლებიც უჭირს. ინტერფეისი მოთხოვნები, მაგალითად, განთქმულნი არიან იმიტომ, რომ თქვენ ყოველთვის ჩანს მისაღებად მოთხოვნები, რომლებიც უბრალოდ არ სასინჯ. საერთო UI მოთხოვნა, როგორც ეს არის “”ეს სისტემა უნდა იყოს მოსახერხებელი.”” რამდენი თქვენგანი არ შეხვდა მეგობრული კომპიუტერი? ერთი სარგებელი ამ ტიპის დიაგრამების, რომ ყველა ხაზი მოდის მსახიობი, რომელიც წარმოადგენს პირი, ეუბნება, რომ რაღაც თქვენს UI აქვს უზრუნველყოს შესაძლებლობების საჭირო, რომ ადამიანი. სხვა სიტყვებით, შეგიძლიათ გამოიყენოთ თანმიმდევრობით დიაგრამების მართოს testable ინტერფეისი მოთხოვნებს.
თანმიმდევრობა დიაგრამების, შესაბამისად, კარგი გვიჩვენოს, თუ რა ხდება, მართვის მოთხოვნები და მუშაობის მომხმარებელს. ეს, როგორც წესი, იწვევს საკითხი, თუმცა, რამდენი უნდა შექმნას? ჩემი პასუხი არის, “”სანამ არ არის საკმარისი.”” თქვენ აპირებს გასარკვევად, როდესაც თქვენ ამის თანმიმდევრობით დიაგრამების, რომ თქვენ მიღწევა, სადაც თქვენ არ მოძიებაში ნებისმიერი ახალი ობიექტი, არ მოძიებაში ნებისმიერი ახალი შეტყობინებები, და რომ თქვენ აკრეფით იგივე მეტი და მეტი. მაგალითში ჯო გაწევრიანების მათემატიკის 101-დან ვიგებთ, რომ ეს პროცესი იქნება იგივე, თუ ჯო უნდოდა ისტორია 101. ასე რომ, უზენაესობის ცერის, თანმიმდევრობა სქემა ყველა ძირითადი ნაკადი ყოველ გამოყენების შემთხვევაში. თანმიმდევრობა სქემა მაღალი დონის, სარისკო სცენარი, და რომ უნდა იყოს საკმარისი. ეს არის ის, თუ რამდენი თანმიმდევრობა დიაგრამების გავაკეთო.
გვახსოვდეს, აქ არის ის, რომ თანამშრომლობის სქემა მხოლოდ განსხვავებული სიტუაცია და შეგიძლიათ წასვლა უკან და მეოთხე შორის თანმიმდევრობით დიაგრამების და თანამშრომლობის დიაგრამების მიიღოს იმ თვალსაზრისით, რომ საუკეთესო ასახავს თქვენს წერტილი.
ზოგჯერ, თქვენ ალბათ ფრაზა “”ურთიერთქმედების დიაგრამები.”” ზოგჯერ ადამიანები ერთობლივად ეხება თანამშრომლობის სქემა და თანმიმდევრობა სქემა, როგორც ურთიერთქმედების სქემა.
კლასი დიაგრამების
კლასი არის კოლექცია ობიექტების საერთო სტრუქტურა, საერთო ქცევის, საერთო ურთიერთობები და საერთო სემანტიკა. თქვენ იპოვით მათ მიერ საგამოცდო ობიექტების მიმდევრობა და თანამშრომლობის დიაგრამების, და ისინი წარმოდგენილია UML როგორც მართკუთხედი სამი კუპე.
გრაფიკი 8: კლასები
პირველ განყოფილებაში აჩვენებს კლასის სახელით, მეორე, მისი სტრუქტურა (ატრიბუტები), ხოლო მესამე გვიჩვენებს მისი ქცევა (ოპერაციები). ეს კუპე შეიძლება იქნას აღკვეთილი, თუმცა, ასე რომ თქვენ ხედავთ მხოლოდ სახელი, მხოლოდ სახელი და ატრიბუტები, ან სამივე. ერთი რამ თქვენ უნდა იცოდეს, რომ ეს არის მნიშვნელოვანი, როდესაც დასახელებისგან კლასი, გამოიყენოთ ლექსიკის domain და აირჩიოთ სტანდარტი. ამ მაგალითად, ჩემი კლასი ყველა სინგულარული არსებითი რომ დაიწყოს დედაქალაქის წერილი. თქვენ შეგიძლიათ ამის გაკეთება განსხვავებულად, და რომ არ აქვს მნიშვნელობა. რას აქვს მნიშვნელობა არის ის, რომ თქვენი პროექტი თქვენ აირჩიოთ სტანდარტული და გამყარებაში მას ისე, რომ ყველაფერი არის თანმიმდევრული მასშტაბით პროექტი.
კლასი დიაგრამების გაჩვენებთ სტატიკურ ხასიათს თქვენს სისტემაში. ეს დიაგრამა ნახოთ არსებობა კლასი და მათი ურთიერთობები ლოგიკური კალენდარი სისტემა. თქვენ მოგიწევთ ბევრი კლასის დიაგრამების მოდელი.
UML მოდელირება ელემენტები გვხვდება კლასის დიაგრამების მოიცავს:
კლასები და მათი სტრუქტურა და ქცევა.
ასოციაცია, აგრეგაციას, დამოკიდებულების და მემკვიდრეობის ურთიერთობები.
მრავალი და ნავიგაცია მაჩვენებლები
როლი სახელები.
შეხედეთ ფიგურა 9. ეს დიაგრამა აჩვენებს ოპერაციების (ქცევის): რა საგანი, რომ კლასი შეუძლია გააკეთოს. მე ჩემი ოპერაციების შევხედავთ ჩემი ურთიერთქმედების დიაგრამები.
გრაფიკი 9: ოპერაციების
აქ მე ვამბობ, რომ მე უნდა შეეძლოს ვთხოვო რეგისტრაციის მენეჯერი დაამატოთ სტუდენტი მათემატიკის
101. რომ აპირებს გარდაქმნა ოპერაცია სახელწოდებით “”addCourse””.
სტრუქტურა კლასის წარმოდგენილია მისი ატრიბუტები. ასე რომ, მე ჩემი ატრიბუტები? საუბარი domain ექსპერტები. შევხედავთ ჩემი მოთხოვნები. ჩემი მაგალითად, გავიგე, რომ თითოეული კურსი შეთავაზებას აქვს ნომერი, ადგილმდებარეობა, და დრო. ეს ითარგმნება, სამი ატრიბუტები.
კლასი. (წარმოდგენილი UML როგორც ხაზის მონათესავე კლასები ალმასის შემდეგი კლასს წარმოადგენს მთელი.)
â € ¢ დამოკიდებულების â € “”სუსტი ფორმა გვიჩვენებს შორის ურთიერთობა კლიენტს და მიმწოდებელი, სადაც კლიენტს არ სემანტიკური ცოდნა მიმწოდებელი. დამოკიდებულების ამბობს: “”მე მჭირდება თქვენი მომსახურება, მაგრამ მე არ ვიცი, რომ არსებობ””. (წარმოდგენილი UML როგორც დატეხილი ხაზის მიუთითებს კლიენტს მიმწოდებელს.)
მოძიების ურთიერთობები, კიდევ ერთხელ, მე დაბრუნდეს ჩემი თანმიმდევრობით გრაფიკაზე. თუ ორი ობიექტი უნდა “”გაიგო””, იქ უნდა იყოს საშუალება ამის გაკეთება (მაგ ურთიერთობას მათი კლასები).
მე, როგორც წესი დაიწყოს და ყველაფერი ასოციაცია. როგორც მე ვაკეთებ მეტი ანალიზი, მე, შესაძლოა, მაქვს აგრეგაციას იმიტომ, რომ მე ვაპირებ უნდა იზრუნოს მშობლისა და შვილის ურთიერთობა. როცა შეღწევას დიზაინი ეტაპი, გავიგებ, რომ მე შეიძლება არ უნდა ასოციაცია რადგან სხვისი აპირებს გაივლის, რომ ობიექტი ერთ-ერთი ჩემი მეთოდები â € “”ასე რომ, რომ ეს დამოკიდებულება.
გრაფიკი 11: ურთიერთობები
ნახაზი 11 ხედავთ ამ ურთიერთობებს. როგორც ასოციაციის ამბობს პროფესორი შეიძლება გაიგო, რომ კურსი შეთავაზებას და კურსი შეთავაზებას ვერ გაიგო, პროფესორი. შეტყობინებები შეიძლება ინიცირებული და მონაცემთა ნაკადის ნებისმიერი მიმართულებით. აგრეგაცია ნაჩვენებია მიერ, რომელსაც ალმასის მიმართ მთელი â € “”ამ შემთხვევაში კურსი შედგება კურსი დამთავრებული. ამის მიზეზი აგრეგაციას იქნება ვუთხრა ჩემს დეველოპერები, რომ თუ ისინი დაეღწია ამ კურსი, ისინი ალბათ უნდა გავაკეთოთ რაღაც განსაკუთრებული კურსი დამთავრებული. დამოკიდებულებები ნაჩვენებია, როგორც დატეხილი ხაზის. ის ამბობდა, რომ რეგისტრაციის მენეჯერი დამოკიდებულია განრიგი ალგორითმი, რომ რამე. განრიგის ალგორითმი ან პარამეტრი ერთ-ერთი მეთოდი და ცხადდება ადგილობრივად ერთ-ერთი მეთოდები რეგისტრაციის მენეჯერი.
მრავალი და ნავიგაცია
მრავალი განსაზღვრავს, თუ როგორ ბევრი ობიექტი მონაწილეობა ურთიერთობა. ეს არის შემთხვევები ერთი კლასის დაკავშირებული ერთ მაგალითად სხვა კლასი. თითოეული ასოციაცია და აგრეგაციას, არსებობს ორი სიმრავლის გადაწყვეტილებები მიიღოს: ერთი თითოეული დასასრულს ურთიერთობა. მრავალი წარმოდგენილია როგორც ნომერი და * გამოიყენება წარმოადგენს მრავალი მრავალი.
გრაფიკი 12: Multiplicity და ნავიგაცია
ერთ-ერთი პროფესორი ობიექტი დაკავშირებული ნულოვანი-ის ოთხი კურსი შეთავაზებას ობიექტები. ერთი კურსი შეთავაზება ობიექტი დაკავშირებული ზუსტად ერთი პროფესორი ობიექტი. მე ამ შევხედოთ და უზრუნველყოს, რომ ეს ემსახურება ჩემი მოთხოვნები. შემიძლია იყოს კურსი შეთავაზებას და ასწავლიან მიერ bunch of პროფესორები? არა, რადგან ეს ამბობს, რომ მე შეიძლება ჰქონდეს მხოლოდ ერთი პროფესორი. შეიძლება ვიყო პროფესორი და შვებულების? დიახ, იმიტომ, რომ ეს ამბობს მაქვს ნულოვანი, რაც შეიძლება, რა თქმა უნდა დატვირთვა. გამოვიყენო მრავალი ხშირად დამეხმარება დაიწყება აღების და განხორციელების ჩემი ბიზნესი წესები. თუ თქვენ გაქვთ, მაგალითად, ბიზნეს წესი, რომელიც ამბობს უნდა ჰქონდეს მინიმუმ 3 სტუდენტი და არაუმეტეს 10, რა თქმა უნდა შესთავაზა სემესტრში, ეს მრავალი ნომრები მეუბნებოდა, მე შეიყვანა, რომ ბიზნეს წესი ამ გეგმას.
ნავიგაცია აჩვენა ისარი, და მიუხედავად იმისა, რომ ასოციაციები და aggregations არის bi- მიმართულებითი ჩვეულებრივ, იგი ხშირად სასურველ შეზღუდოს ნავიგაცია ერთი მიმართულებით. როდესაც ნავიგაცია შეზღუდულია, an ARROWHEAD ემატება მიუთითოს სანავიგაციო მიმართულებით. ერთი რამ გავაკეთო ანალიზის დროს და დიზაინის ფაზა შევხედოთ, რაც მე მინდა, რომ იყოს uni მიმართულებითი. გამოსული arrow ამ სქემა, მე ვიტყვი, რომ რეგისტრაციის მენეჯერი შეგიძლიათ გააგზავნოთ გზავნილი კურსი, რადგან იცის, კურსის არსებობს. მაგრამ კურსი არ აქვს იდეა, რომ რეგისტრაციის მენეჯერი არსებობს, ასე რომ კურსი ვერ ინიცირება გაგზავნა. ახლა მონაცემები ვერ შემოვა, მათ შორის; მაგალითად, რეგისტრაციის მენეჯერი შეგიძლიათ ვთხოვო კურსი თუ ეს ღია და კურსი შეიძლება ითქვას, რომ ეს არის. მაგრამ მხოლოდ რეგისტრაციის მენეჯერი შეიძლება დაიწყოს საუბარი.
ცხადია, მიზანი აქ არის მიიღოს როგორც ბევრი ისრები, როგორც თქვენ შეგიძლიათ მიერ დროს თქვენ დასრულდა დიზაინი, იმიტომ, რომ ეს ბევრად უფრო ადვილია სისტემის შენარჩუნება მემკვიდრეობის ნაჩვენები სამკუთხედის. ეს გვიჩვენებს, რომ პროფესორი არის რეგისტრაცია მომხმარებელი, როგორც სტუდენტი. ახლა, სიტყვა გაფრთხილება. მემკვიდრეობა არის სასარგებლო, თუმცა, მიზანი არ არის იმდენი მემკვიდრეობის, როგორც თქვენი სისტემის საშუალებით. მე ვნახე რამდენიმე მართლაც სასტიკი სისტემები, სადაც მათ ჰქონდათ სამკვიდრო 17 დონეზე ღრმა. თუ ისინი შეცვალა ერთი რამ, ის გახდა კატასტროფა. ასე რომ წესი thumb არის გამოიყენოს მემკვიდრეობის მხოლოდ მაშინ, როდესაც თქვენ ნამდვილად აქვთ სამკვიდრო სიტუაცია.
სახელმწიფო გარდამავალ დიაგრამები
სახელმწიფო გარდამავალ დიაგრამაზე ცხოვრების ისტორიის მოცემულ კლასში. ეს გვიჩვენებს, რომ მოვლენები, რომელიც იწვევს გადასვლას ერთი სახელმწიფო სხვა, და ქმედებები, რომ გამოიწვიოს სახელმწიფო ცვლილება.
გრაფიკი 14: სახელმწიფო გარდამავალ სქემა
გამოვიყენო სახელმწიფო გარდამავალ დიაგრამები ობიექტი კლასების, რომ, როგორც წესი, აქვს ბევრი დინამიური ქცევა. ღილაკს არის € | ღილაკს off; მე არ ვაპირებ ამის გაკეთება სახელმწიფო გრაფიკი იგი. მაგრამ ობიექტის კლასი რომ აქვს ბევრი დინამიური ქცევა, მე ალბათ აპირებს უნდა გავერკვეთ სახელმწიფოების ობიექტები.
დავიწყებ უჩვენებს სახელმწიფო, რომელიც არის მომრგვალებული სამკუთხედის. შემიძლია დაწყება სახელმწიფოები და შემიძლია გაჩერება სახელმწიფოებს, რომლებიც ნაჩვენებია როგორც ხარი თვალში. შემიძლია ასევე აქვს გადასვლები სახელმწიფოებს შორის, ან მცველი გადასვლები (რამ, რომ მოხდეს, როდესაც მხოლოდ მაშინ, როცა მდგომარეობა არის ჭეშმარიტი), ან რამ, რომ მოხდეს, როდესაც მე შიგნით სახელმწიფო. ვუყურებ ამ დიაგრამაზე და ვხედავ სახელმწიფო გარდამავალ სქემა, რა თქმა უნდა შეთავაზებას. იგი იწყება ინიციალიზაციისას სახელმწიფო და ვრჩები, რომ სახელმწიფო, სანამ მივიღებ “”დაამატოთ სტუდენტი”” გაგზავნა. როდესაც მე კიდევ რომ გაგზავნა, მე ჩემს გრაფი სტუდენტი ნულოვანი და მე გადასვლას Open სახელმწიფო. თქვენ ხედავთ გრაფიკი 14 რომ მაქვს ჩანაწერი, რის გამოც ის არ არის, რომ მე მაქვს ორი გზა მისაღებად შევიდა, რომ სახელმწიფო. იგი აცხადებს, რომ არ აქვს მნიშვნელობა, თუ როგორ მოვიდა სახელმწიფო, მინდა, რომ დარეგისტრირდეთ სტუდენტი. როდესაც მე გასვლა, რომ სახელმწიფო, გრაფი ცვლილებების შენარჩუნება სიმღერა სტუდენტთა რაოდენობის, რა თქმა უნდა. შემიძლია დამემატებინა სტუდენტები სანამ მივიღებ 10, და მერე წასვლა Close სახელმწიფო. მას შემდეგ, რაც, რა თქმა უნდა იქნება, მე გადასვლას stop სახელმწიფო. არ აქვს მნიშვნელობა, სადაც მე ვარ მაშინ, თუ მივიღებ გაუქმება ღონისძიებები გარდამავალი, მე აცნობოს ჩემს სტუდენტებს და შემდეგ გადასვლას გაჩერება სახელმწიფო.
ობიექტის კლასი რომ აქვს ბევრი დინამიური ქცევა, ეს კარგად ღირს ამის გაკეთება სახელმწიფო სქემა სახელური, ყველაფერი, რაც უნდა მოხდეს. ჰკითხეთ საკუთარ თავს, თუ რა ხდება, როდესაც მე გაგზავნა? რა გავაკეთო, როდესაც მივიღებ გაგზავნა? რა მესიჯები მე არ გაგზავნის? ბევრი იმ შეტყობინებები გახდეს ოპერაციების ობიექტი კლასის, როგორც ამ მაგალითს, სადაც რჩეულებში სტუდენტი ოპერაცია. ბევრი ეს ქმედებები, როგორიცაა შექმნის რაოდენობა, აუმატეთ რაოდენობა, შემოწმების რაოდენობა, ეს ყველა გახდეს კერძო ოპერაციებში, რომ კონკრეტული ობიექტი კლასის და სახელმწიფო სქემა არის, სადაც მე ვხედავ, რომ.
იცით, თუ თქვენ გაქვთ დინამიური ობიექტზე კლასში? კიდევ ერთხელ, დაბრუნდეს თანმიმდევრობა დიაგრამები. თუ თქვენ გაქვთ ობიექტის კლასი, რომელიც არის ბევრი თანმიმდევრობა დიაგრამების და ის მიღების და გაგზავნის ბევრი შეტყობინებები, რომ კარგი მაჩვენებელია, რომ ეს არის საკმაოდ დინამიური ობიექტზე კლასი და ეს უნდა ალბათ სახელმწიფო გრაფიკი იგი. ასევე aggregations, სადაც თქვენ უნდა მთელი მისი ნაწილები, მე სახელმწიფო გრაფიკი ყოველ საერთო მთლიანად. მე ამის გაკეთება ძირითადად იმიტომ, რომ საერთო მთელი ხშირად პასუხისმგებელია შეტყობინებები, რაც დინამიური.
კომპონენტი დიაგრამები
რა თქმა უნდა, არსებობს სისტემა შეიძლება აშენდეს გათვალისწინების გარეშე ფიზიკურ სამყაროში. სწორედ იქ, სადაც კომპონენტი დიაგრამების მოდის. ისინი გამოიყენება ასახავს ორგანიზაციებისა და დამოკიდებულებები შორის პროგრამული კომპონენტების, მათ შორის კოდის კომპონენტები, აწარმოებს დროს კომპონენტები, ან შემსრულებელი კომპონენტი. კომპონენტები შოუები დიდი მართკუთხედი ორი პატარა ოთხკუთხედს მხარეს, როგორც ჩანს დიაგრამა 15.
გრაფიკი 15: კომპონენტები
იმ ტურში რამ წარმოადგენს ინტერფეისი (ხშირად უწოდებენ lollipop notation). ამ შემთხვევაში, ისინი, რომ Register.exe არის დამოკიდებული ინტერფეისის ორივე Course.dll და People.dll. ეს ნიშნავს, რომ თუ ამ ინტერფეისების შეიცვლება, ეს აისახება Register.exe. მე ვიცი, რომ არსებობს ამ წესი, როდესაც თქვენ მშენებლობის ინტერფეისი, რომელიც აცხადებს, რომ “”შენ არ შეცვალოს ინტერფეისი.”” მაგრამ ვინმეს რეალურად მუშაობს, სადაც ეს წესი ძალაში? ეს დიაგრამა გვეუბნება, თუ რა ინტერფეისების გამოიყენება რა executables გაშვებული ჩემი პროცესორები.
გრაფიკი 16: განლაგების სქემა
გაგრძელების UML
ბოლო რამ მინდა ხაზი გავუსვა, რომ UML არის ის, რომ შეიძლება გაგრძელდეს. როდესაც მათ ააშენეს UML, ისინი ძალიან გონივრულად მიხვდა, რომ არ არსებობს გზა, მათ შეუქმნიდა notation, რომელიც შეიძლება, გთხოვთ, ყველა ადამიანი ყველა დროის. ასე რომ, ისინი მოგვცა კონცეფცია სტერეოტიპი. სტერეოტიპი ამბობს მე შეუძლია მიიღოს ძირითადი მოდელირება ელემენტს და მისცეს მას მეტი მნიშვნელობა აქვს. სტერეოტიპები შეიძლება გამოყენებულ იქნას დაალაგეთ გაფართოება და ასოციაციები, მემკვიდრეობის ურთიერთობები, კლასი, და კომპონენტები.
დიაგრამა 17: ვებ სტერეოტიპი მაგალითად
დიაგრამა 17 გვიჩვენებს სქემა ჩვენი ვებ სტერეოტიპები. ვებ გვერდზე, როგორც წესი, პერსონალის, რომელიც ეშვება სერვერზე და პერსონალი, რომელიც მუშაობს კლიენტს. თუ თქვენ მშენებლობის ვებ დაფუძნებული პროგრამები, რა გაშვებული კლიენტი და სერვერი არის სასიცოცხლო მნიშვნელობა აქვს. ასე რომ, ჩვენ გვაქვს მთელი რიგი სტერეოტიპები, რომ აჩვენოს, რომ. პატარა დისკები წარმოადგენს რამ, რომ აწარმოებს სერვერზე. ასე რომ, მხოლოდ შევხედავთ ამ ერთი სქემა მე ვხედავ რა ეშვება სერვერზე, რაც გადის კლიენტს, და ბიზნესის ობიექტების მათ გამკლავება.

“——————————————————————————————————————————————————

Unterstützung Übersetzung: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”Die UML ist die Standardsprache für die Spezifizierung, Visualisierung, Konstruktion und alle Artefakte eines Software-Systems zu dokumentieren.””
Aktivitätsdiagramme
Der logische Ort zu starten einige der UML-Diagramme zu Fuß durch auf Aktivitätsdiagrammen suchen.
Abbildung 2: Aktivitätsdiagramm
Aktivitätsdiagramme zeigen den Ablauf der Steuerung. Wie in Abbildung 2 dargestellt, können Sie Aktivitäten sehen, wie abgerundete Rechtecke dargestellt. Aktivitäten sind in der Regel Aktion Staaten â € “”besagt, dass der Übergang automatisch in den nächsten Zustand nach der Aktion abgeschlossen ist. Der im Kreis gefüllt stellt den Beginn des Aktivitätsdiagramm â € “”wo der Ablauf der Steuerung beginnt. Transitions als Pfeile dargestellt zeigen, wie Sie von einer Aktivität zur nächsten bewegen. Synchronisationsbalken zeigen, wie Aktivitäten parallel geschehen. Ich kann einen Übergang schützen, der sagt “”Ich will dich nur auf diese Tätigkeit zu gehen, wenn diese Bedingung erfüllt ist,”” und ich kann Ihnen zeigen, wo sie aufhört. Nun, wenn Sie ein bestimmtes Alter sind, werden Sie wahrscheinlich in diesem Aktivitätsdiagramm sehen und denken: “”hmm â € |., Die wie ein Flussdiagramm sieht”” Und das ist genau das, was es ist, es sei denn ich tue es nicht auf der Programmierebene nach unten. Normalerweise verwende ich früh auf ein Aktivitätsdiagramm ziemlich in meiner Analyse und Design-Prozess Business-Workflow zu zeigen. Ich werde sie auch zu zeigen, verwenden, in denen jedes meiner Anwendungsfälle in einer Aktivität sein könnte zu veranschaulichen, welche Anwendungsfall zu geschehen hat. Ich benutze Aktivitätsdiagramme auch zeigen, wie sich die Dinge zwischen meinen Anwendungsfälle fließen.
Aber einer der großen Vorteile von UML ist seine Vielseitigkeit. So, während ich Aktivitätsdiagramme am Anfang des Lebenszyklus nutzen, so dass sie in einer anderen Phase andere können vollständig nutzen. Ich habe Leute auf der Design-Ebene Diagramme nach unten verwenden Aktivität gesehen, wo sie für eine bestimmte Klasse einen sehr komplizierten Satz Algorithmen hatte. Und viele Menschen, die sie verwenden, um die Strömung zwischen den Methoden einer Klasse zu zeigen.
das System. Schauspieler sind als Strichmännchen dargestellt.
Abbildung 4: Schauspieler
Das Beispiel, das ich für diese Einführung in UML aufgearbeitet ist ein kleines Modell eines Kurses Registrierungssystem. So in diesem Fall tun würde, das erste, was ich als meine Analyseprozess zu fragen beginnen, “”die mit diesem System zu interagieren wird?””
Für die Kursanmeldung Modell habe ich einen Registrar, ein Professor und ein Student. Ich habe auch ein externes Billing-System. Dieses Abrechnungssystem qualifiziert auch als Schauspieler. (Siehe, ein Schauspieler muss nicht eine Person sein, € “”es etwas gibt, das mit dem System interagiert, ist aber außerhalb des Systems.)
Ein Anwendungsfall ist eine Folge von ähnlichen Transaktionen von einem Akteur im System in einem Dialog durchgeführt. Oder, um es in Englisch zu stellen, ein Anwendungsfall ist ein Stück Funktionalität. Und hier ist der Schlüssel: es ist nicht ein Software-Modul â € “”es ist etwas, das Wert auf den Schauspieler zur Verfügung stellt.
Use Cases sind als Ovale dargestellt, und der einfachste Weg, um sie zu finden ist bei jedem Ihrer Schauspieler zu schauen und sich fragen, warum sie das System verwenden möchten. In meinem Fall wird mein Registrar den Lehrplan zu halten, mein Professor ein Register zu beantragen wird, meine Schüler den Zeitplan hält, und mein Abrechnungssystem empfängt die Zahlungsinformationen ein. Also habe ich meine Anwendungsfälle schaffen, indem sie von der Sicht des Kunden suchen und zu fragen: “”ja, Herr System Schauspieler, warum wollen Sie das System zu benutzen? Welchen Wert stellt dieses System für Sie?””
Der nächste Schritt, sobald Sie festgestellt haben, wie Sie Ihre Schauspieler mit dem System interagieren können, ist Ihre Anwendungsfälle dokumentieren. Jeder Anwendungsfall muss mit dem Fluss der Ereignisse dokumentiert werden, und dies wird von dem Schauspieler Sicht getan. Es sollte Detail ein, was das System muss mit dem Schauspieler liefern, wenn der Anwendungsfall ausgeführt wird. Typischerweise wird es Dinge wie zeigen, wie der Anwendungsfall beginnt und endet. Welche Dinge ist, dass Anwendungsfall zu tun? Sie werden den normalen Ablauf der Ereignisse haben (was ich die “”glückliche Tage”” Szenario nennen), wo alles funktioniert. Dann werden Sie die abnorme Fluss der Ereignisse erhalten, die “”Regentag”” Szenario. Was passiert, wenn das System nicht funktioniert? Ich habe durch die Dokumentation meiner Fluss der Ereignisse gefunden, die ich immer mit dem glücklichen Tage Szenario starten.
Nehmen wir als Beispiel, zu Fuß bis zu einem Geldautomaten. Sie gehen an die ATM-up und Ihre Karte ein. Sie fragt nach Ihrer PIN-Nummer. Sie geben es, und Sie werden gefragt, was Sie tun möchten. Sie sagen, “”ich etwas Geld wollen.”” Es fragt, wo das Geld sollte aus genommen werden. Sie sagen, dass es es von Ihrem Girokonto zu übernehmen. Es fragt sich, wie viel. Sie sagen $ 100,00. Dann geschieht Magie â € | es Sie 100,00 $ gibt. Dann fragt es, ob Sie eine weitere Transaktion soll. Sie sagen, nein. Es gibt Ihnen Ihre Karte zurück, gibt Ihnen eine Quittung, und die Transaktion ist vorbei. Das ist der glücklichen Tag Szenario.
Zweites Szenario. Sie gelangen in die ATM, legen Sie Ihre Karte und Ihre PIN eingeben. Die ATM sagt Ihnen, es ist die falsche PIN. Sie geben Ihre Nummer erneut. Auch hier werden Sie gesagt, dass die PIN nicht korrekt ist. Sie in meinem Kurs Anmeldung Beispiel, zum Beispiel, können Sie sehen, dass es eine Menge “”, wenn X dann Y”” sind Workflows. Das ist, wo Sie Ihre Kunden möchten Ihnen zu helfen. Die Einigung Anfang bedeutet, dass Ihre Kunden diese Szenarien versteht und sagt: “”Ja, das ist, was wir wollen.”” Use Cases sind eine gute Möglichkeit, um sicherzustellen, dass das, was Sie bauen ist wirklich das, was der Kunde will, weil sie die Schauspieler zeigen, die Anwendungsfälle, und die Beziehungen zwischen ihnen.
Abbildung 5: Use-Case-Diagramm
So haben wir ein großes Diagramm, das grafisch zeigt mir, was? Die Antwort ist einfach â € “”es ein großes Diagramm ist, das einen guten Überblick über das System zeigt. Es zeigt, was außerhalb des Systems ist (Aktoren) und die Funktionalität, die das System (Anwendungsbeispiele) bereitstellen muss. Wenn es ein Legacy-System ist, müssen Sie berücksichtigen, hier, wo Sie damit umgehen. Zwingen Sie mich mit dieser Art von Schnittstellen sehr früh im Projekt zu arbeiten, bedeutet, dass ich nicht mit der Aussicht, zu warten, bis Codierung beginnt, um herauszufinden, konfrontiert werden, wie ich zu dieser Black-Box zu sprechen werde, die ich nicht ändern kann .
Eine weitere Sache, die Sie über Anwendungsfälle wissen sollten, ist der Anwendungsfall Realisierung. Dies ist das “”Wie”” des Anwendungsfalls. Es ist in der Regel ein Eimer, die drei verschiedene Arten von Diagrammen enthält: Sequenzdiagramme, Collaboration-Diagramme und ein Klassendiagramm, das wir einen Blick auf teilnehmenden Klassen nennen. Anwendungsfall Realisierungen sind im Grunde eine Art des Zusammen Gruppieren einer Anzahl von Artefakten an der Konstruktion eines Anwendungsfall bezieht.
Sequenzdiagramme
Sequenzdiagramme zeigen Objekt-Interaktionen in einer zeitlichen Abfolge angeordnet sind. Ich kann den Fluss von Ereignissen, unter welchem Objekte und Interaktionen I benötigt, die Funktionalität durch den Fluss von Ereignissen spezifiziert zu erreichen.
Abbildung 6: Sequenzdiagramm
6 zeigt, wie ein Student erfolgreich zu einem Kurs hinzugefügt wird. Der Student (wir ihn Joe nennen) füllt in einigen Informationen und sendet das Formular. Die Form spricht dann mit dem Manager und sagt: “”hinzufügen Joe zu Math 101.”” Der Manager sagt Math 101, die es einem Schüler hinzuzufügen hat. Math 101 sagt zu Kapitel 1 “”sind Sie offen?”” In diesem Fall Abschnitt 1 Antworten, dass sie offen sind, so Math 101 Abschnitt 1 hinzufügen Diesen Studenten erzählt. Wieder Sequenzdiagramme sind großartige Werkzeuge am Anfang, weil sie Ihnen und Ihren Kunden Schritt-für-Schritt zeigen, was passieren muss.
Aus einer Analyse Sicht habe ich im Laufe der Jahre, dass Sequenzdiagramme als sehr leistungsfähig sind mir zu helfen Anforderungen treiben; Anforderungen vor allem die schwer zu finden sind. Benutzeroberfläche Anforderungen, zum Beispiel, sind berüchtigt, weil Sie scheinen immer Anforderungen zu erhalten, die sind einfach nicht prüfbar. Eine gemeinsame UI Anforderung wie das ist “”dieses System soll benutzerfreundlich sein.”” Wie viele von Ihnen haben einen freundlichen Computer erfüllt? Einer der Vorteile dieser Art von Diagrammen ist, dass jede Zeile von einem Schauspieler kommen, die eine Person darstellt, sagt Ihnen, dass etwas in Ihrem UI eine Fähigkeit von dieser Person benötigt zur Verfügung stellen muss. Mit anderen Worten: Sie können Sequenzdiagramme auszutreiben prüfbar Benutzeroberfläche Anforderungen verwenden.
Sequenzdiagramme sind daher gut für das Zeigen, was los ist, für Anforderungen zu vertreiben, und für den Kunden arbeiten. Das führt in der Regel zu der Frage, obwohl, wie viele brauchen Sie erstellen? Meine Antwort ist “”, bis Sie genug zu tun.”” Du wirst herausfinden, wenn Sie Sequenzdiagramme tun, dass Sie einen Punkt erreichen, wo Sie keine neuen Objekte zu finden, keine neuen Nachrichten zu finden, und dass Sie die gleiche Sache immer und immer sind die Eingabe. Also, Faustregel tun ein Ablaufdiagramm für jeden grundlegenden Ablauf eines jeden Anwendungsfall Im Beispiel von Joe Math Verbindung 101 erfahren wir, dass der Prozess der gleiche wäre, wenn Joe 101. Geschichte anschließen wollte. Haben Sie ein Sequenzdiagramm für High-Level, riskante Szenarien, und das sollte genug sein. Das ist, wie viele Sequenzdiagramme ich.
hier zu erinnern ist, dass ein Kollaborationsdiagramm nur eine andere Ansicht eines Szenarios ist, und Sie können hin und her zwischen Sequenzdiagramme und Kollaborationsdiagrammen gehen, um die Ansicht, die Ihren Punkt am besten zeigt.
Gelegentlich kann man den Ausdruck “”Interaktionsdiagramme”” hören. Manchmal beziehen sich die Menschen kollektiv auf ein Kollaborationsdiagramm und ein Ablaufdiagramm als Interaktionsdiagramm.
Klassendiagramme
Eine Klasse ist eine Sammlung von Objekten mit gemeinsamen Struktur, gemeinsames Verhalten, gemeinsame Beziehungen und gemeinsame Semantik. Man findet sie, indem sie die Objekte in der Reihenfolge und Kollaborationsdiagramme untersuchen, und sie werden in der UML als Rechteck mit drei Fächern vertreten.
Abbildung 8: Klassen
Die erste Kammer zeigt den Klassennamen, die zweite zeigt seine Struktur (Attribute) und die dritte zeigt sein Verhalten (Operationen). Diese Abteile unterdrückt werden, aber so, dass man einfach den Namen sehen können, nur den Namen und die Attribute, oder alle drei. Eine Sache, die Sie sollten auch wissen, ist, dass es wichtig ist, wenn Klassen zu benennen, das Vokabular der Domäne zu verwenden und einen Standard auswählen. Für diesen Fall sind meine Klassen alle Substantive im Singular, die mit einem Großbuchstaben beginnen. Sie können wählen, um es anders zu tun, und das spielt keine Rolle. Was tut, ist Sache, dass, bevor Sie Ihr Projekt ein Standard auswählen und dabei bleiben, so dass alles, was über das Projekt im Einklang steht.
Klassendiagramme zeigen Ihnen die statische Natur des Systems. Diese Diagramme zeigen die Existenz von Klassen und deren Beziehungen in der logischen Ansicht eines Systems. Sie werden in einem Modell viele Klassendiagramme haben.
Die UML-Modellierungselemente in Klassendiagrammen gefunden sind:
Klassen und deren Struktur und Verhalten.
Assoziation, Aggregation, Abhängigkeit und Vererbungsbeziehungen.
Multiplicity und Navigationsindikatoren
Rollennamen.
Werfen Sie einen Blick auf Abbildung 9. Dieses Diagramm zeigt Operationen (Verhalten): was ein Objekt in dieser Klasse zu tun. Ich finde meine Operationen an meine Interaktionen Diagramme suchen.
Abbildung 9: Operationen
Hier sage ich, dass ich die Registrierung Manager fragen, um einen Schüler zu Math hinzufügen
101, die in einer Operation genannt zu übersetzen geht “”addCourse.””
Die Struktur einer Klasse wird durch seine Attribute dargestellt. Wie finde ich meine Attribute? Im Gespräch mit Domain-Experten. Durch meine Anforderungen suchen. In meinem Beispiel erfahre ich, dass jeder Kursangebot hat eine Nummer, einen Ort und eine Zeit. Dies führt zu drei Attribute aus.
Klassen. (Vertreten in der UML als Linie die entsprechenden Klassen mit einem Diamanten neben der Klasse verbindet die ganze darstellt.)
â € ¢ Abhängigkeit â € “”zeigt eine schwächere Form der Beziehung zwischen einem Kunden und einem Lieferanten, wo der Kunde nicht semantisches Wissen des Lieferanten hat. Eine Abhängigkeit, sagt: “”Ich brauche Ihre Dienste, aber ich weiß nicht, dass es dich gibt.”” (Vertreten in der UML als eine gestrichelte Linie zeigt die vom Client an den Lieferanten.)
Für Beziehungen, noch einmal, ich gehe zurück zu meinem Sequenzdiagramm. Wenn zwei Objekte zu “”reden”” müssen, muss es ein Mittel, dies zu tun sein (das heißt, eine Beziehung zwischen ihren Klassen).
Ich beginnen in der Regel aus und machen eine Vereinigung alles. Da ich mehr Analyse zu tun, könnte ich finde ich eine Aggregation, weil ich zu kümmern einer Eltern-Kind-Beziehung bin zu haben. Wenn ich in der Design-Phase erhalten, finde ich heraus, dass ich nicht einen Verein brauchen könnte, weil jemand anderes das Objekt in einen meiner Methoden â € passieren wird “”, so mache ich es eine Abhängigkeit.
Abbildung 11: Beziehungen
In Abbildung 11 sehen Sie diese Beziehungen. Als Verein, sagt der Professor zum Lehrangebot und dem Kursangebot sprechen kann, kann mit dem Professor sprechen. Nachrichten können eingeleitet werden und die Daten können aus jeder Richtung fließen. Die Aggregation wird, indem der Diamant in Richtung der ganzen â € “”in diesem Fall ein Kurs besteht aus Lehrangebot gezeigt. Der Grund für diese Aggregation wäre meine Entwickler zu sagen, dass, wenn sie von diesem Kurs loswerden, sie werden wahrscheinlich etwas Besonderes mit den Lehrangebot zu tun haben. Abhängigkeiten werden als gestrichelte Linie dargestellt. Es ist zu sagen, dass die Registrierung Manager auf dem Schedule-Algorithmus hängt etwas zu tun. Der Schedule-Algorithmus ist entweder ein Parameter für eine der Methoden oder lokal durch eine der Methoden der Registration-Manager erklärt.
Multiplicity und Navigation
Multiplicity definiert, wie viele Objekte in einer Beziehung teilhaben. Es ist die Anzahl von Instanzen einer Klasse zu einer Instanz der anderen Klasse verwandt. Für jede Assoziation und Aggregation gibt es zwei Vielzahl Entscheidungen zu treffen: eine für jedes Ende der Beziehung. Multiplizität wird als Zahl dargestellt, und a * verwendet, um eine Vielzahl von vielen darzustellen.
Abbildung 12: Multiplicity und Navigation
Ein Professor Objekt bezieht sich auf die Null-zu-vier Lehrangebot Objects. Ein Kursangebot Objekt ist genau einem Professor Objekt bezogen. Ich benutze dies zu betrachten und zu gewährleisten, dass dies meine Anforderungen behandelt. Kann ich ein Lehrangebot und durch ein Bündel von Professoren Team gelehrt werden? Nein, denn dies sagt, dass ich nur ein Professor haben kann. Kann ich einen Professor und sein Sabbatical sein? Ja, denn dies sagt, ich habe eine Null wie möglich natürlich Last. Ich Vielzahl verwenden sehr oft, mir zu helfen beginnen die Erfassung und meine Geschäftsregeln zu implementieren. Wenn Sie zum Beispiel, dass eine Geschäftsregel sagt, dass Sie mindestens 3 Studenten und nicht mehr als 10 für einen Kurs in einem Semester angeboten werden, diese Vielzahl Zahlen sagen mir haben muss ich, dass Geschäftsregel in diesen Plan aufgenommen haben.
Navigation wird durch einen Pfeil dargestellt, und obwohl Verbände und Aggregationen bidirektionale standardmäßig sind, ist es oft wünschenswert Navigation auf eine Richtung zu beschränken. Wenn die Navigation beschränkt ist, wird eine Pfeilspitze hinzugefügt, um die Navigationsrichtung anzuzeigen. Eines der Dinge, die ich während der Analyse- und Designphase zu tun ist, schauen, was ich will unidirektional sein. Indem Sie den Pfeil in diesem Diagramm, sage ich, dass die Registration-Manager eine Nachricht an den Kurs senden können, weil es der Kurs existiert kennt. Aber der Kurs hat keine Ahnung, dass die Registrierung-Manager vorhanden ist, so dass der Kurs kann keine Nachricht hinterlassen. Jetzt können Daten zwischen ihnen fließen; zum Beispiel kann die Registrierung Manager den Kurs fragen, ob es geöffnet ist und kann den Kurs sagen, dass es ist. Aber nur der Registration-Manager das Gespräch beginnen.
Offensichtlich ist das Ziel hier ist es, so viele Pfeile zu erhalten, wie Sie durch die Zeit, können Sie entwerfen beendet haben, weil es eine viel einfachere System ist Vererbung zu halten ist mit einem Dreieck angezeigt. Dies zeigt, dass der Professor eine Registrierung Mitglied ist, als der Student ist. Nun ein Wort der Warnung. Die Vererbung ist nützlich, aber das Ziel ist nicht so viel Erbe als Ihrem System verwenden können. Ich habe einige wirklich brutal Systeme gesehen, wo sie tief Erbe 17-Ebenen hatte. Wenn sie eine Sache verändert, wurde es eine Katastrophe. So ist die Faustregel Vererbung verwenden nur, wenn Sie wirklich tun haben eine Erbschaft Situation.
Zustandsübergangsdiagramme
Ein Zustandsdiagramm zeigt die Lebensgeschichte einer bestimmten Klasse. Es zeigt die Ereignisse, die einen Übergang von einem Zustand zum anderen führen, und die Aktionen, die von einer Zustandsänderung zur Folge haben.
Abbildung 14: Zustandsdiagramm
Ich benutze Zustandsübergangsdiagramme für Objektklassen, die typischerweise viel dynamisches Verhalten haben. Der Button ist auf â € | die Taste ausgeschaltet ist; Ich werde nicht ein Zustandsdiagramm für sie zu tun. Aber Objektklassen, die eine Menge dynamisches Verhalten haben, werde ich wahrscheinlich zu haben, in die Zustände der Objekte zu suchen.
Ich beginne mit einem Zustand zeigt, die ein abgerundetes Dreieck ist. Ich kann Startzustände haben, und ich kann Haltezustände haben, die als Bullen Augen gezeigt werden. Ich kann auch Übergänge zwischen den Zuständen haben, oder Wachübergänge (Dinge, die, wenn nur geschehen, wenn eine Bedingung erfüllt ist), oder Dinge, die passieren, wenn ich in den Zustand bin. Ich sehe auf diesem Diagramm und sehen Sie die Zustandsübergangsdiagramm für einen Kursangebot. Es beginnt in der Initialisierungszustand, und ich bleibe in diesem Zustand, bis ich eine “”add Student”” Meldung. Als ich diese Nachricht erhalten, habe ich meine Graf von Studenten auf Null und ich in den offenen Zustand übergehen. Sie werden in Abbildung 14, dass ich einen Eintrag haben, und der Grund, warum es da ist, dass ich zwei Möglichkeiten, in diesen Zustand zu bekommen. Er sagt, dass, egal wie man in den Zustand kommen, möchte ich Ihnen den Schüler zu registrieren. Wenn ich diesen Zustand zu beenden, um die Anzahl Änderungen Überblick über die Anzahl der Studenten halten im Kurs. Ich kann das Hinzufügen Studenten zu halten, bis ich bis 10 bekommen, und dann gehe ich zum Schließen Zustand. Sobald der Kurs abgeschlossen ist, ich in den Stoppzustand übergehen. Egal wo ich dann bin, wenn ich das Abbrechen Event-Übergang, ich benachrichtigen meine Schüler und dann in den Stoppzustand übergehen.
Für Objektklassen, die eine Menge dynamisches Verhalten haben, ist es lohnt sich ein Zustandsdiagramm zu tun, alles im Griff zu bekommen, die zu geschehen hat. Fragen Sie sich, was passiert, wenn ich eine Nachricht bekommen? Was mache ich, wenn ich die Nachricht bekommen? Welche Nachrichten Ich habe zu schicken? Viele dieser Nachrichten werden Operationen der Objektklasse, wie in diesem Beispiel, in dem Unternehmen ein Student eine Operation ist. Viele dieser Aktionen, wie die Zählung Einstellung, die Zählung inkrementiert, die Zählung überprüft, diese alle zu privaten Operationen dieser bestimmten Objektklasse und ein Zustandsdiagramm ist, wo ich das sehen.
Wie wissen Sie, wenn Sie eine dynamische Objektklasse haben? Wieder einmal geht zurück in die Sequenzdiagramme. Wenn Sie eine Objektklasse, die auf eine Menge von Sequenzdiagrammen ist und es wird immer und viele Nachrichten zu senden, ist das ein guter Hinweis darauf, es eine ziemlich dynamische Objektklasse ist, und es sollte wohl ein Zustandsdiagramm für sie. Auch für Aggregationen, wo Sie die ganze seiner Teile haben, ich habe ein Zustandsdiagramm für jedes Aggregat insgesamt. Ich tue dies vor allem, weil das Aggregat ganze für die Verwaltung der Messaging oft verantwortlich ist, die es dynamisch macht.
Komponentendiagramme
Natürlich kann kein System die physische Welt ohne Berücksichtigung gebaut werden. Das ist, wo Komponentendiagramme in kommen. Sie werden verwendet, um die Organisationen und Abhängigkeiten zwischen Software-Komponenten zu veranschaulichen, einschließlich Quellcode-Komponenten, Laufzeitkomponenten oder eine ausführbare Komponente. Komponenten zeigt als großes Rechteck mit zwei kleineren Rechtecke auf der Seite, wie in 15 gesehen.
Abbildung 15: Komponenten
Diese Runde Dinge stellen Schnittstellen dar (oft als Lollipop-Notation). In diesem Fall zeigen sie, dass die Register.exe sowohl von Schnittstellen zum Course.dll und People.dll abhängt. Das heißt, wenn diese Schnittstellen ändern, wird es die Register.exe auswirken. Ich weiß, dass es diese Regel ist, wenn Sie Schnittstellen Gebäude sind, die sagt: “”Du sollst nicht die Schnittstelle ändern.”” Aber funktioniert jemand eigentlich, wo diese Regel durchgesetzt wird? Dieses Diagramm zeigt uns, welche Schnittstellen verwendet werden, durch welche ausführbaren Dateien auf meinem Prozessoren ausgeführt werden.
Abbildung 16: Verteilungsdiagramm
Erweitern von UML
Das letzte, was ich über die UML zu betonen möchte ist, dass es erweitert werden kann. Als sie die UML gebaut, sie erkannten, sehr klug, dass es keine Möglichkeit gab sie eine Notation schaffen könnte, die alle Menschen die ganze Zeit gefallen könnte. So gaben sie uns das Konzept eines Stereotyps. Ein Stereotyp sagt, ich kann eine grundlegende Modellierungselement nehmen und es mehr Sinn zu geben. Stereotypien kann verwendet werden, zu klassifizieren und zu erweitern Verbände, Vererbungsbeziehungen, Klassen und Komponenten.
Abbildung 17: Web Stereotyp Beispiel
Abbildung 17 zeigt die Darstellung unserer Web Klischees. Eine Webseite hat in der Regel Dinge, die auf dem Server und so läuft die auf dem Client ausgeführt wird. Wenn Sie die Erstellung von Web-basierten Anwendungen, was auf dem Client ausgeführt wird und der Server ist von entscheidender Bedeutung. So haben wir eine ganze Reihe von Stereotypen, die das zeigen. Die kleinen Räder repräsentieren Dinge, die auf dem Server ausgeführt. Also nur durch an diesem ein Diagramm sucht, kann ich sehen, was auf dem Server ausgeführt wird, was auf dem Client ausgeführt, und welche Business-Objekte, die sie haben, zu beschäftigen.

“——————————————————————————————————————————————————

μετάφραση Υποστήριξη: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”Η UML είναι η τυπική γλώσσα για τον καθορισμό, την οπτικοποίηση, την κατασκευή, και την τεκμηρίωση όλων των αντικειμένων του συστήματος λογισμικού.””
δραστηριότητα Διαγράμματα
Η λογική θέση για να αρχίσει το περπάτημα μέσα από μερικά από τα διαγράμματα UML είναι κοιτάζοντας τα διαγράμματα δραστηριότητας.
Σχήμα 2: Διάγραμμα Δραστηριότητας
διαγράμματα δραστηριότητας δείχνουν τη ροή του ελέγχου. Όπως φαίνεται στο Σχήμα 2, μπορείτε να δείτε τις δραστηριότητες εκπροσωπήθηκαν ως στρογγυλεμένα ορθογώνια. Οι δραστηριότητες είναι συνήθως κρατών δράση â € “”αναφέρει ότι η μετάβαση αυτόματα στην επόμενη κατάσταση μετά τη δράση είναι πλήρης. Το συμπληρώνεται κύκλος αντιπροσωπεύει την έναρξη του διαγράμματος δραστηριότητας â € “”, όπου η ροή ξεκινά ελέγχου. Μεταβάσεις εμφανίζονται ως βέλη δείχνουν το πώς θα περάσουμε από δραστηριότητα σε δραστηριότητα. Ο συγχρονισμός μπάρες δείχνουν πώς οι δραστηριότητες συμβαίνουν παράλληλα. Μπορώ να προφυλαχθεί μια μετάβαση που λέει “”θέλω να πάω σε αυτή τη δραστηριότητα μόνο αν αυτή η συνθήκη είναι αληθής,« και μπορώ να σας δείξει πού να σταματήσει. Τώρα, εάν είστε μια ορισμένη ηλικία, θα πρέπει πιθανώς να εξετάσουμε αυτό το διάγραμμα δραστηριότητας και να σκεφτεί, “”Χμμ â € |. Που μοιάζει με ένα διάγραμμα ροής”” Και αυτό είναι ακριβώς αυτό που είναι, εκτός από εγώ δεν το κάνω κάτω στο επίπεδο του προγραμματισμού. Συνήθως, μπορώ να χρησιμοποιήσω ένα διάγραμμα δραστηριότητας αρκετά νωρίς στη διαδικασία της ανάλυσης και του σχεδιασμού μου για να δείξει τη ροή εργασίας των επιχειρήσεων. Θα επίσης να τους χρησιμοποιήσετε για να δείξει πού κάθε μία από τις περιπτώσεις χρήσης μου θα μπορούσε να είναι σε μια δραστηριότητα για να τονίσει ποια περίπτωση χρήσης πρέπει να συμβεί. Χρησιμοποιώ επίσης διαγράμματα δραστηριότητας για να δείξει πώς ρέουν τα πράγματα μεταξύ των περιπτώσεων χρήσης μου.
Αλλά ένα από τα μεγάλα πράγματα για την UML είναι η ευελιξία του. Έτσι, ενώ μπορώ να χρησιμοποιήσω διαγράμματα δραστηριότητας στην αρχή του κύκλου ζωής, άλλοι μπορούν να τα χρησιμοποιήσουν σε μια διαφορετική φάση εντελώς. Έχω δει ανθρώπους να χρησιμοποιούν δραστηριότητας διαγράμματα κάτω στο επίπεδο του σχεδιασμού, όπου είχαν μια πολύ περίπλοκη σειρά από αλγόριθμους για μια συγκεκριμένη κατηγορία. Και πολλοί άνθρωποι τα χρησιμοποιούν για να δείξει τη ροή μεταξύ των μεθόδων της κλάσης.
το σύστημα. Οι φορείς που εκπροσωπούνται ως φιγούρες.
Σχήμα 4: Ηθοποιοί
Το παράδειγμα που έχω εργαστεί για αυτή την εισαγωγή για UML είναι ένα μικρό μοντέλο ενός συστήματος καταχώρησης πορεία. Έτσι, σε αυτή την περίπτωση, το πρώτο πράγμα που θα ήθελα να κάνω κατά την έναρξη της διαδικασίας η ανάλυσή μου είναι να ρωτήσω, “”ο οποίος πρόκειται να αλληλεπιδράσει με αυτό το σύστημα;””
Για το μοντέλο εγγραφής Φυσικά, έχω μια γραμματέα, έναν καθηγητή και έναν φοιτητή. Έχω επίσης ένα εξωτερικό σύστημα τιμολόγησης. Αυτό το σύστημα χρέωσης χαρακτηρίζεται επίσης ως ηθοποιός. (Βλέπε, ένας ηθοποιός δεν πρέπει να είναι ένα πρόσωπο â € “”αυτό είναι κάτι που αλληλεπιδρά με το σύστημα, αλλά είναι έξω από το σύστημα.)
Μια περίπτωση χρήσης είναι μια σειρά από σχετικές πράξεις που πραγματοποιούνται από έναν ηθοποιό στο σύστημα σε ένα παράθυρο διαλόγου. Ή, για να το θέσω στην αγγλική γλώσσα, μια περίπτωση χρήσης είναι ένα κομμάτι της λειτουργικότητας. Και εδώ είναι το κλειδί: δεν είναι μια ενότητα λογισμικού â € “”είναι κάτι που προσφέρει αξία για τον ηθοποιό.
Τα Χρήση περιπτώσεις εμφανίζονται ως οβάλ, και ο ευκολότερος τρόπος για να τους βρείτε είναι να δούμε κάθε ένα από ηθοποιούς σας και ρωτήστε τον εαυτό σας γιατί θέλουν να χρησιμοποιήσουν το σύστημα. Στην περίπτωσή μου, γραμματέα μου πρόκειται να διατηρήσει το πρόγραμμα σπουδών, καθηγητής μου πρόκειται να ζητήσει ένα ρόστερ, μαθητής μου διατηρεί το πρόγραμμα, και του συστήματος χρέωσης μου λαμβάνει τις πληροφορίες χρέωσης. Γι ‘αυτό και δημιουργούν περιπτώσεις χρήσης μου κοιτάζοντας το από την άποψη του πελάτη και ζητώντας, “”έτσι, ηθοποιός σύστημα mister, γιατί θέλετε να χρησιμοποιήσετε το σύστημα; Τι αξία έχει αυτό το σύστημα παρέχει σε σας;””
Το επόμενο βήμα, αφού έχετε προσδιορίσει πώς ηθοποιούς σας θα πρέπει να αλληλεπιδρά με το σύστημα, είναι do τεκμηριώνει περιπτώσεις χρήσης σας. Κάθε περίπτωση χρήσης πρέπει να τεκμηριώνεται με τη ροή των γεγονότων, και αυτό γίνεται από την πλευρά του ηθοποιού του άποψη. Θα πρέπει να λεπτομέρεια ό, τι το σύστημα πρέπει να παρέχει στον δράστη όταν εκτελείται η περίπτωση χρήσης. Συνήθως θα δείξει τα πράγματα όπως το πώς ξεκινά και τελειώνει με την περίπτωση χρήσης. Ποια πράγματα κάνει ότι περίπτωση χρήσης πρέπει να κάνουμε; Θα έχετε την κανονική ροή των γεγονότων (αυτό που εγώ αποκαλώ το “”Happy Days”” σενάριο), όπου όλα λειτουργούν. Στη συνέχεια θα έχετε την ανώμαλη ροή των γεγονότων, το «βροχερή ημέρα» σενάριο. Τι συμβαίνει όταν το σύστημα δεν λειτουργεί; Έχω διαπιστώσει από την τεκμηρίωση της ροής μου γεγονότα που ξεκινούν πάντα με το σενάριο ευτυχισμένες μέρες.
Πάρτε ως παράδειγμα, το περπάτημα μέχρι ένα μηχάνημα αυτόματης ανάληψης. Μπορείτε να περπατήσετε μέχρι το ΑΤΜ και τοποθετήστε την κάρτα σας. Ζητά για τον αριθμό PIN σας. Μπορείτε να εισάγετε, και θα σας ζητηθεί ό, τι θα θέλατε να κάνετε. Λέτε “”θέλω κάποια χρήματα.”” Ζητά όπου τα χρήματα θα πρέπει να λαμβάνονται από το. Μπορείτε να το πείτε για να το πάρει από τον έλεγχο του λογαριασμού σας. Ζητά πόσο. Λέτε $ 100,00. Στη συνέχεια μαγικό συμβαίνει â € | σας δίνει $ 100,00. Στη συνέχεια, σας ρωτά αν θέλετε μια άλλη συναλλαγή. Μπορείτε να πω όχι. Σας δίνει πίσω την κάρτα σας, σας δίνει μια απόδειξη, και η συναλλαγή έχει τελειώσει. Αυτό είναι το ευτυχισμένο σενάριο ημέρα.
Δεύτερο σενάριο. Μπορείτε να πάτε μέχρι το ATM, τοποθετήστε την κάρτα σας, και εισάγετε το PIN σας. Το ΑΤΜ σας λέει ότι είναι το λάθος PIN. Μπορείτε να εισαγάγετε ξανά τον αριθμό σας. Και πάλι σας πουν ότι το PIN είναι λάθος. Μπορείτε Στην πορεία μου παράδειγμα εγγραφής, για παράδειγμα, μπορείτε να δείτε ότι υπάρχουν πολλά “”αν X τότε Y”” ροές εργασίας. Αυτό είναι όπου θέλετε τον πελάτη σας για να σας βοηθήσει. Να πάρει η συμφωνία σημαίνει νωρίς πελάτης σας καταλαβαίνει αυτά τα σενάρια και λέει “”ναι, αυτό είναι ό, τι θέλουμε.”” Χρησιμοποιήστε τις περιπτώσεις είναι ένας πολύ καλός τρόπος για να εξασφαλιστεί ότι αυτό που χτίζετε είναι πραγματικά ό, τι θέλει ο πελάτης, επειδή δείχνουν τους ηθοποιούς, τις περιπτώσεις χρήσης, καθώς και τις σχέσεις μεταξύ τους.
Σχήμα 5: Χρησιμοποιήστε το διάγραμμα περίπτωση
Έτσι έχουμε μια μεγάλη διάγραμμα που μου τι δείχνει γραφικά; Η απάντηση είναι απλή â € “”είναι ένα μεγάλο διάγραμμα που δείχνει μια καλή εικόνα του συστήματος. Δείχνει τι είναι έξω από το σύστημα (ηθοποιοί) και τη λειτουργικότητα που το σύστημα πρέπει να παρέχει (περιπτώσεις χρήσης). Αν υπάρχει ένα σύστημα κληρονομιά που πρέπει να ληφθούν υπόψη, εδώ είναι όπου μπορείτε να ασχοληθεί με το θέμα. Αναγκάζοντάς με να συνεργαστεί με αυτούς τους τύπους των διεπαφών πολύ νωρίς στο πρόγραμμα σημαίνει ότι δεν θα βρεθούμε αντιμέτωποι με την προοπτική να περιμένουν μέχρι κωδικοποίησης αρχίζει να καταλάβω πώς θα πάω να μιλήσω σε αυτό το μαύρο κουτί που δεν μπορώ να αλλάξω .
Ένα ακόμα πράγμα που πρέπει να ξέρετε για τις περιπτώσεις χρήσης είναι η περίπτωση χρήσης υλοποίηση. Αυτό είναι το «πώς» της χρήσης υπόθεσης. Είναι συνήθως ένα κουβά που περιέχει τρεις διαφορετικούς τύπους των διαγραμμάτων: διαγράμματα ακολουθίας, διαγράμματα συνεργασίας, και ένα διάγραμμα κατηγορίας που ονομάζουμε θέα τάξεις που συμμετέχουν. Χρησιμοποιήστε το συνειδητοποιήσεις την περίπτωση είναι ουσιαστικά ένας τρόπος συγκεντρώνοντας μια σειρά από αντικείμενα που σχετίζονται με το σχεδιασμό μιας υπόθεσης χρήση.
ακολουθία Διαγράμματα
διαγράμματα δείχνουν Ακολουθία αντικείμενο αλληλεπιδράσεις διατάσσονται σε μια χρονική ακολουθία. Μπορώ να χρησιμοποιήσω τη ροή των γεγονότων για να καθορίσει τι αντικείμενα και οι αλληλεπιδράσεις θα πρέπει να ολοκληρώσει τη λειτουργικότητα που καθορίζεται από τη ροή των γεγονότων.
Σχήμα 6: διάγραμμα ακολουθίας
Το σχήμα 6 δείχνει πώς ένας μαθητής με επιτυχία θα προστεθεί σε μια σειρά μαθημάτων. Ο μαθητής (ας τον καλέσει Τζο) συμπληρώνει κάποιες πληροφορίες και υποβάλλει τη φόρμα. Το έντυπο συνέχεια μιλά για το διαχειριστή και λέει “”add Joe να Math 101.”” Ο διευθυντής λέει Math 101 που έχει να προσθέσετε ένα μαθητή. Μαθηματικά 101 αναφέρει στην Ενότητα 1 “”είναι το άνοιγμα;”” Στην περίπτωση αυτή, το τμήμα 1 απαντήσεις ότι είναι ανοιχτή, έτσι Μαθηματικά 101 λέει ενότητα 1 για να προσθέσετε αυτό το μαθητή. Και πάλι, διαγράμματα ακολουθίας είναι μεγάλα εργαλεία στην αρχή, επειδή εσείς και ο πελάτης σας δείχνουν βήμα-βήμα τι πρέπει να συμβεί.
Από ένα σημείο ανάλυσης του άποψη, έχω διαπιστώσει όλα αυτά τα χρόνια ότι τα διαγράμματα ακολουθίας είναι πολύ ισχυρές, βοηθώντας με οδηγήσει απαιτήσεις? κυρίως απαιτήσεις που είναι δύσκολο να βρεθούν. απαιτήσεις διεπαφής χρήστη, για παράδειγμα, είναι διαβόητη επειδή φαίνεται πάντα να πάρετε τις απαιτήσεις που δεν είναι ακριβώς ελέγξιμες. Μια κοινή απαίτηση UI όπως αυτό είναι «το σύστημα αυτό πρέπει να είναι φιλική προς το χρήστη.”” Πόσοι από εσάς έχετε συνάντησε ένα φιλικό υπολογιστή; Ένα από τα πλεονεκτήματα αυτών των τύπων των διαγραμμάτων είναι ότι κάθε γραμμή που προέρχεται από έναν ηθοποιό που αντιπροσωπεύει ένα πρόσωπο, σας λέει ότι κάτι στο UI σας πρέπει να παρέχει μια ικανότητα που απαιτείται από το εν λόγω πρόσωπο. Με άλλα λόγια, μπορείτε να χρησιμοποιήσετε τα διαγράμματα ακολουθίας να διώξουν ελέγξιμες απαιτήσεις διεπαφής χρήστη.
διαγράμματα ακολουθίας είναι, ως εκ τούτου, καλό για δείχνει τι συμβαίνει, για την οδήγηση τις απαιτήσεις, καθώς και για την εργασία με τους πελάτες. Αυτό συνήθως οδηγεί στο ερώτημα, όμως, πόσα χρειάζεστε για να δημιουργήσετε; Η απάντησή μου είναι, “”μέχρι να κάνει αρκετά.”” Θα πάμε για να μάθετε όταν κάνετε διαγράμματα ακολουθίας που θα φτάσει σε ένα σημείο όπου δεν μπορείτε να βρείτε όλα τα νέα αντικείμενα, δεν βρίσκει καμία νέα μηνύματα, και ότι πληκτρολογείτε το ίδιο πράγμα ξανά και ξανά. Στο παράδειγμα του Joe ενώνει Μαθηματικά 101, μαθαίνουμε ότι η διαδικασία θα ήταν το ίδιο αν ο Joe ήθελαν να ενταχθούν Ιστορία 101. Έτσι, κανόνας, κάνουμε ένα διάγραμμα ακολουθίας για κάθε βασική ροή κάθε περίπτωση χρήσης. Κάνετε ένα διάγραμμα ακολουθίας για υψηλού επιπέδου, επικίνδυνη σενάρια, και ότι θα πρέπει να είναι αρκετό. Αυτό είναι το πώς πολλοί ακολουθία διαγράμματα κάνω.
να θυμόμαστε εδώ, είναι ότι ένα διάγραμμα συνεργασίας είναι απλά μια διαφορετική άποψη ενός σεναρίου και μπορείτε να πάτε πίσω και εμπρός μεταξύ διαγράμματα ακολουθίας και διαγράμματα συνεργασίας για να πάρει την άποψη που δείχνει καλύτερα την άποψή σας.
Περιστασιακά, μπορεί να ακούσετε τη φράση “”διαγράμματα αλληλεπίδρασης.”” Μερικές φορές οι άνθρωποι θα αναφέρονται συλλογικά σε ένα διάγραμμα συνεργασίας και διάγραμμα ακολουθίας ως διάγραμμα αλληλεπίδρασης.
Κλάση Διαγράμματα
Μια κατηγορία είναι μια συλλογή από αντικείμενα με κοινή δομή, κοινή συμπεριφορά, κοινή σχέσεις και κοινή σημασιολογία. Μπορείτε να τα βρείτε με την εξέταση τα αντικείμενα σε σειρά και συνεργασία διαγράμματα, και εκπροσωπούνται στη UML ως ένα ορθογώνιο με τρία διαμερίσματα.
Σχήμα 8: Μαθήματα
Το πρώτο διαμέρισμα δείχνει το όνομα της κλάσης, ο δεύτερος δείχνει τη δομή (ιδιότητες) του και η τρίτη δείχνει τη συμπεριφορά της (επιχειρήσεις). Αυτά τα διαμερίσματα μπορεί να κατασταλεί, όμως, έτσι ώστε να μπορείτε να δείτε μόνο το όνομα, μόνο το όνομα και τα χαρακτηριστικά, ή και τα τρία. Ένα πράγμα που πρέπει επίσης να γνωρίζετε είναι ότι είναι σημαντικό, κατά την ονομασία τάξεις, να χρησιμοποιούν το λεξιλόγιο της περιοχής και να επιλέξετε ένα πρότυπο. Για αυτό το παράδειγμα, τα μαθήματά μου είναι όλα μοναδικά ουσιαστικά που αρχίζουν με κεφαλαίο γράμμα. Μπορείτε να επιλέξετε να το κάνετε με διαφορετικό τρόπο, και ότι δεν έχει σημασία. Τι έχει σημασία είναι ότι πριν το έργο σας να επιλέξετε ένα πρότυπο και να κολλήσει με αυτό, έτσι ώστε όλα να είναι συνεπής σε όλη του έργου.
Class διαγράμματα που δείχνουν την στατική φύση του συστήματός σας. Αυτά τα διαγράμματα δείχνουν την ύπαρξη των τάξεων και τις σχέσεις τους με τη λογική άποψη του συστήματος. Θα έχετε πολλές διαγράμματα τάξη σε ένα μοντέλο.
Τα στοιχεία μοντελοποίησης UML που βρέθηκαν στην τάξη διαγράμματα περιλαμβάνουν:
Τάξεις και τη δομή και τη συμπεριφορά τους.
Association, συνάθροιση, την εξάρτηση, και την κληρονομιά σχέσεις.
Οι δείκτες πολλαπλότητα και την πλοήγηση
ονόματα ρόλο.
Ρίξτε μια ματιά στο σχήμα 9. Αυτό το διάγραμμα δείχνει λειτουργίες (συμπεριφορά): ό, τι ένα αντικείμενο σε αυτή την κατηγορία μπορεί να κάνει. Θεωρώ πράξεις μου, κοιτάζοντας τις αλληλεπιδράσεις διαγράμματα μου.
Σχήμα 9: Λειτουργίες
Εδώ λέω ότι πρέπει να είναι σε θέση να ζητήσει από τον διαχειριστή εγγραφής για να προσθέσετε ένα μαθητή να Math
101. Αυτό πρόκειται να μεταφραστεί σε μια λειτουργία που ονομάζεται “”addCourse.””
Η δομή μιας τάξης αντιπροσωπεύεται από τα χαρακτηριστικά του. Λοιπόν, πώς μπορώ να βρω τα χαρακτηριστικά μου; Μιλώντας με ειδικούς του χώρου. Κοιτάζοντας τις απαιτήσεις μου. Στο παράδειγμά μου, έχω μάθει ότι κάθε προσφορά μάθημα έχει έναν αριθμό, μια θέση, και ένα χρόνο. Αυτό μεταφράζεται με τρία χαρακτηριστικά.
τάξεις. (Που εκπροσωπούνται στο UML ως μια γραμμή που συνδέει τις σχετικές κατηγορίες με ένα διαμάντι δίπλα στην τάξη που εκπροσωπεί το σύνολο.)
â € ¢ Εξάρτησης â € “”μια ηπιότερη μορφή που δείχνει τη σχέση μεταξύ ενός πελάτη και ενός προμηθευτή όπου ο πελάτης δεν έχει σημασιολογική γνώση του προμηθευτή. Μια εξάρτηση λέει “”χρειάζομαι τις υπηρεσίες σας, αλλά δεν ξέρετε ότι υπάρχουν.”” (Που εκπροσωπούνται στο UML ως διακεκομμένη γραμμή με κατεύθυνση από τον πελάτη στον προμηθευτή.)
Για να βρείτε τις σχέσεις, για άλλη μια φορά, να πάω πίσω στο διάγραμμα ακολουθίας μου. Αν δύο αντικείμενα πρέπει να “”μιλήσει””, θα πρέπει να υπάρχει ένας τρόπος για να το κάνετε αυτό (δηλαδή, μια σχέση ανάμεσα στις τάξεις τους).
Εγώ συνήθως ξεκινούν και κάνουν τα πάντα ένωση. Όπως κάνω περισσότερη ανάλυση, θα μπορούσα να βρω έχω μια συνάθροιση επειδή είμαι πρόκειται να πρέπει να ασχοληθούν με μια σχέση γονέα-παιδιού. Όταν μπει στο στάδιο του σχεδιασμού, θεωρώ ότι δεν μπορεί να χρειαστεί μια ένωση, επειδή κάποιος άλλος πρόκειται να περάσει αυτό το αντικείμενο σε μία από τις μεθόδους μου â € “”γι ‘αυτό το μετόχι κάνει.
Εικόνα 11: Σχέσεις
Στο Σχήμα 11 μπορείτε να δείτε αυτές τις σχέσεις. Ως ένωση, λέει ο καθηγητής μπορεί να μιλήσει με το μάθημα που προσφέρει, και την Προσφορά του μαθήματος μπορούν να μιλήσουν στον καθηγητή. μπορεί να ξεκινήσει μηνύματα και τα δεδομένα μπορεί να ρέει από οποιαδήποτε κατεύθυνση. Συνάθροιση παρουσιάζεται έχοντας το διαμάντι προς το σύνολο του â € “”στην περίπτωση αυτή ένα μάθημα αποτελείται από Προσφορές γκολφ. Ο λόγος για αυτή την συνάθροιση θα ήταν να πω στους προγραμματιστές μου ότι αν απαλλαγούμε από αυτή την πορεία, που κατά πάσα πιθανότητα θα πρέπει να κάνουμε κάτι ιδιαίτερο με τις προσφορές γκολφ. Οι εξαρτήσεις εμφανίζεται ως διακεκομμένη γραμμή. Είναι λέγοντας ότι ο διαχειριστής εγγραφής εξαρτάται από το Πρόγραμμα Αλγόριθμος να κάνει κάτι. Το Πρόγραμμα αλγόριθμος είναι είτε μια παράμετρος για μία από τις μεθόδους ή δηλώνεται τοπικά από μία από τις μεθόδους του Διαχειριστή Εγγραφής.
Πολλαπλότητα και Πλοήγηση
Πολλαπλότητα καθορίζει πόσα αντικείμενα συμμετέχουν σε μια σχέση. Είναι ο αριθμός των περιπτώσεων μια κατηγορία που σχετίζονται με ένα παράδειγμα της άλλης κατηγορίας. Για κάθε ένωση και συγκέντρωση, υπάρχουν δύο πολλαπλότητα αποφάσεις για να κάνουν: μία για κάθε άκρο της σχέσης. Πολλαπλότητα αντιπροσωπεύεται ως αριθμός και η * χρησιμοποιείται για να αντιπροσωπεύσει μια πολλαπλότητα των πολλών.
Εικόνα 12: πολλαπλότητα και πλοήγηση
Ένας καθηγητής αντικειμένου σχετίζεται με το μηδέν-to-τέσσερις Προσφορά γκολφ αντικείμενα. Ένα μάθημα που προσφέρει αντικειμένου σχετίζεται με ακριβώς ένα καθηγητή αντικειμένου. Μπορώ να χρησιμοποιήσω αυτό για να δούμε και να διασφαλίσει ότι αυτό το χειρίζεται τις απαιτήσεις μου. Μπορώ να είμαι μια Προσφορά του μαθήματος και να την ομάδα-διδάσκονται από μια δέσμη των καθηγητών; Όχι, γιατί αυτό λέει ότι μπορώ να έχω μόνο έναν καθηγητή. Μπορώ να είμαι καθηγητής και να είναι σε εκπαιδευτική άδεια; Ναι, γιατί αυτό λέει έχω ένα μηδέν όσο το δυνατόν φορτίο πορεία. Χρησιμοποιώ πολλαπλότητα αρκετά συχνά για να βοηθήσει να ξεκινήσετε τη λήψη και την εφαρμογή των κανόνων της επιχείρησής μου. Αν έχετε, για παράδειγμα, ένας επιχειρησιακός κανόνας που λέει ότι πρέπει να έχετε τουλάχιστον 3 φοιτητές και όχι περισσότερο από 10 για ένα μάθημα που πρέπει να προσφέρονται σε ένα εξάμηνο, οι αριθμοί αυτοί πολλαπλότητα μου πείτε έχω ενσωματωθεί ότι η επιχείρησή κανόνας σε αυτό το σχέδιο.
Πλοήγηση παρουσιάζεται από ένα βέλος, και παρόλο που οι ενώσεις και συναθροίσεων είναι αμφίδρομη από προεπιλογή, είναι συχνά επιθυμητό να περιορίζουν την πλοήγηση σε μια κατεύθυνση. Όταν πλοήγησης είναι περιορισμένη, μια αιχμή βέλους προστίθεται για να δείξει την κατεύθυνση πλοήγησης. Ένα από τα πράγματα που κάνω κατά τη διάρκεια των φάσεων ανάλυσης και σχεδιασμού είναι να δούμε τι θέλω να είναι μονής κατεύθυνσης. Με την τοποθέτηση του βέλους σε αυτό το διάγραμμα, θα ήθελα να πω ότι ο Διαχειριστής Εγγραφή μπορεί να στείλει ένα μήνυμα στο γκολφ, γιατί ξέρει υπάρχει το γκολφ. Αλλά η πορεία δεν έχει ιδέα ότι υπάρχει ο Διαχειριστής Εγγραφή, έτσι ώστε το γκολφ δεν μπορεί να κινήσει ένα μήνυμα. Τώρα τα δεδομένα μπορεί να ρέει μεταξύ τους? για παράδειγμα, ο Διαχειριστής Εγγραφή μπορεί να ζητήσει από το γκολφ αν είναι ανοικτή και η πορεία μπορεί να πει ότι είναι. Αλλά μόνο ο Διαχειριστής Εγγραφή μπορεί να ξεκινήσει η συζήτηση.
Προφανώς, ο στόχος εδώ είναι να πάρετε όσες βέλη όπως μπορείτε να από τη στιγμή που έχετε τελειώσει το σχεδιασμό, γιατί είναι ένα πολύ πιο εύκολο σύστημα να διατηρήσει Κληρονομιάς παρουσιάζεται με ένα τρίγωνο. Αυτό δείχνει ότι ο καθηγητής είναι ένας Εγγραφή Χρήστη, όπως είναι ο Φοιτητής. Τώρα, μια λέξη της προειδοποίησης. Κληρονομικότητα είναι χρήσιμη, όμως, ο στόχος δεν είναι να χρησιμοποιήσει όσο κληρονομιά και το σύστημά σας θα επιτρέψει. Έχω δει κάποια πραγματικά βάναυση συστήματα όπου είχαν κληρονομιά 17-επίπεδα βαθιά. Αν αλλάξει κάτι, έγινε μια καταστροφή. Έτσι, ο γενικός κανόνας είναι να χρησιμοποιήσετε κληρονομιά μόνο όταν πραγματικά έχουν μια κατάσταση κληρονομιά.
Μετάβασης κατάστασης Διαγράμματα
Ένα διάγραμμα μετάβασης κατάστασης δείχνει την ιστορία της ζωής μιας δεδομένης κατηγορίας. Δείχνει τα γεγονότα που προκαλούν μια μετάβαση από το ένα κράτος στο άλλο, καθώς και τις ενέργειες που προκύπτουν από την αλλαγή κατάστασης.
Σχήμα 14: Διάγραμμα μετάπτωσης
Χρησιμοποιώ μεταβατική κατάσταση διαγράμματα για τις κατηγορίες αντικειμένων που συνήθως έχουν πολύ δυναμική συμπεριφορά. Το κουμπί βρίσκεται σε € | το κουμπί είναι απενεργοποιημένο? Είμαι δεν πρόκειται να κάνει ένα κράτος γράφημα για αυτό. Αλλά κλάσεις αντικειμένων που έχουν πολλή δυναμική συμπεριφορά, είμαι κατά πάσα πιθανότητα θα πρέπει να εξετάσει τις καταστάσεις των αντικειμένων.
Αρχίζω δείχνοντας μια κατάσταση, η οποία είναι ένα στρογγυλεμένο τρίγωνο. Μπορώ να έχω κράτη αρχή, και μπορώ να έχω κράτη στάση, οι οποίες εμφανίζονται ως ταύροι μάτια. Επίσης, μπορεί να έχει μεταβάσεις μεταξύ των κρατών, ή μεταβάσεις φρουρά (τα πράγματα που συμβαίνουν όταν μόνο όταν μια συνθήκη είναι αληθής), ή πράγματα που συμβαίνουν όταν είμαι μέσα στο κράτος. Κοιτάζω αυτό το διάγραμμα και να δούμε το διάγραμμα μεταβατική κατάσταση για την προσφορά μαθημάτων. Ξεκινά στην κατάσταση αρχικοποίησης, και μένω σε αυτή την κατάσταση μέχρι να πάρω ένα μήνυμα “”προσθήκη μαθητής””. Όταν παίρνω αυτό το μήνυμα, μπορώ να ορίσω καταμέτρηση μου φοιτητή στο μηδέν και τη μετάβαση στην ανοικτή κατάσταση. Θα δείτε στο Σχήμα 14, που έχω μια καταχώρηση, και ο λόγος για τον οποίο υπάρχει είναι ότι έχω δύο τρόπους για να πάρει σε αυτή την κατάσταση. Λέει ότι δεν έχει σημασία το πώς θα έρθει στην κατάσταση, θέλω να καταχωρήσετε το μαθητή. Όταν βγείτε από αυτήν την κατάσταση, οι αλλαγές που μετράνε για να παρακολουθείτε τον αριθμό των μαθητών στο μάθημα. Μπορώ να συνεχίσουμε να προσθέτουμε μαθητές μέχρι να φτάσετε στο 10, και στη συνέχεια να πάω στο Close κατάσταση. Μόλις το μάθημα έχει ολοκληρωθεί, θα μεταβεί στην κατάσταση stop. Δεν έχει σημασία πού είμαι, στη συνέχεια, αν πάρω τη μετάβαση να ακυρώσετε την Εκδήλωση, θα ενημερώσει τους μαθητές μου και στη συνέχεια μετάβαση στην κατάσταση stop.
Για τις κατηγορίες αντικειμένων που έχουν πολλή δυναμική συμπεριφορά, είναι καλά αξίζει τον κόπο να κάνει ένα διάγραμμα κατάσταση για να πάρετε μια λαβή για ό, τι έχει να συμβεί. Ρωτήστε τον εαυτό σας τι συμβαίνει όταν παίρνω ένα μήνυμα; Τι μπορώ να κάνω όταν παίρνω το μήνυμα; Τι μηνύματα να έχω να στείλω; Πολλά από αυτά τα μηνύματα να γίνουν πράξεις της κατηγορίας αντικειμένου, όπως σε αυτό το παράδειγμα, όπου προσθέσει ένας μαθητής είναι μια λειτουργία. Πολλές από αυτές τις δράσεις, όπως η ρύθμιση την καταμέτρηση, που αυξάνει την αρίθμηση, ελέγχοντας την καταμέτρηση, όλα αυτά γίνονται ιδιωτικές επιχειρήσεις της συγκεκριμένης κατηγορίας αντικείμενο και ένα διάγραμμα κατάσταση είναι όταν βλέπω ότι.
Πώς μπορείτε να γνωρίζετε αν έχετε μια δυναμική τάξη αντικειμένου; Για άλλη μια φορά, να πάει πίσω στα διαγράμματα ακολουθίας. Εάν έχετε μια κλάση αντικειμένων που είναι σε πολλά διαγράμματα ακολουθίας και να πάρει και στέλνοντας πολλά μηνύματα, αυτό είναι μια καλή ένδειξη ότι είναι μια αρκετά δυναμική τάξη αντικειμένου και θα πρέπει πιθανώς να έχετε μια κατάσταση γράφημα για αυτό. Επίσης, για συναθροίσεις, όπου έχετε το σύνολο των μερών της, να κάνω μια κατάσταση διάγραμμα για κάθε συνολικό σύνολο. Το κάνω αυτό κυρίως γιατί η συνολική σύνολό της είναι συχνά υπεύθυνη για τη διαχείριση της ανταλλαγής μηνυμάτων, το οποίο το καθιστά δυναμική.
διαγράμματα συστατικό
Φυσικά κανένα σύστημα δεν μπορεί να οικοδομηθεί χωρίς να λαμβάνεται υπόψη το φυσικό κόσμο. Αυτός είναι όπου συστατικό διαγράμματα έρχονται σε. Χρησιμοποιούνται για να απεικονίσουν τις οργανώσεις και τις εξαρτήσεις μεταξύ των στοιχείων λογισμικού, συμπεριλαμβανομένων των συστατικών του πηγαίου κώδικα, εκτελέστε τα συστατικά του χρόνου, ή ένα εκτελέσιμο συστατικό. Τα στοιχεία είναι δείχνει σαν ένα μεγάλο ορθογώνιο με δύο μικρότερα ορθογώνια στην πλευρά, όπως φαίνεται στο σχήμα 15.
Σχήμα 15: Εξαρτήματα
Οι εν λόγω γύρο τα πράγματα αντιπροσωπεύουν διασυνδέσεις (που συχνά αποκαλείται γλειφιτζούρι σημειογραφία). Στην περίπτωση αυτή, δείχνουν ότι η Register.exe εξαρτάται από διασυνδέσεις τόσο στο Course.dll και το People.dll. Αυτό σημαίνει ότι αν αυτές οι διασυνδέσεις αλλάξει, θα επηρεάσουν το Register.exe. Ξέρω ότι υπάρχει αυτός ο κανόνας όταν είστε οικοδόμηση διεπαφές που λέει “”εσύ δεν πρέπει να αλλάξετε το περιβάλλον.”” Αλλά μήπως κανείς πραγματικά εργασία, όπου ο κανόνας αυτός επιβάλλεται; Αυτό το διάγραμμα μας λέει τι διασυνδέσεις χρησιμοποιούνται από ό, τι τα εκτελέσιμα τρέχει σε επεξεργαστές μου.
Σχήμα 16: Ανάπτυξη διάγραμμα
Η επέκταση UML
Το τελευταίο πράγμα που θέλω να τονίσω σχετικά με τη UML είναι ότι μπορεί να παραταθεί. Όταν χτίστηκε το UML, που πολύ σοφά συνειδητοποίησε ότι δεν υπήρχε τρόπος που θα μπορούσε να δημιουργήσει ένα συμβολισμό που θα μπορούσε να ευχαριστήσει όλους τους ανθρώπους όλη την ώρα. Έτσι, μας έδωσαν την ιδέα ενός στερεότυπο. Ένα στερεότυπο λέει ότι μπορώ να πάρω ένα βασικό στοιχείο μοντελοποίησης και να της δώσει περισσότερο νόημα. Στερεότυπα μπορεί να χρησιμοποιηθεί για να ταξινομήσει και να επεκτείνει τις ενώσεις, τις σχέσεις κληρονομιά, μαθήματα, και τα συστατικά.
Εικόνα 17: Web παράδειγμα στερεότυπο
Το Σχήμα 17 δείχνει το διάγραμμα των στερεοτύπων μας στο Web. Μια ιστοσελίδα έχει τυπικά πράγματα που τρέχει στον server και πράγματα που τρέχει στον υπολογιστή-πελάτη. Αν είστε οικοδόμηση Web-based εφαρμογές, τι τρέχει στον υπολογιστή-πελάτη και του διακομιστή είναι ζωτικής σημασίας. Έτσι, έχουμε μια ολόκληρη σειρά από στερεότυπα που δείχνουν ότι. Οι μικρές ρόδες αντιπροσωπεύουν πράγματα που εκτελούνται στο διακομιστή. Έτσι απλά κοιτάζοντας αυτό το διάγραμμα μπορώ να δω τι τρέχει στον server, τι τρέχει στον πελάτη, και τι δουλειά αντικείμενα που έχουν να αντιμετωπίσουν.

“——————————————————————————————————————————————————

અનુવાદ આધાર: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”UML, સ્પષ્ટ બતાવે છે, બાંધવા, અને સોફ્ટવેર સિસ્ટમ તમામ વસ્તુઓનો દસ્તાવેજીકરણ માટે પ્રમાણભૂત ભાષા છે.””
પ્રવૃત્તિ ડાયગ્રામ્સ
લોજિકલ સ્થળ UML આકૃતિઓ કેટલાક મારફતે વૉકિંગ શરૂ કરવા માટે પ્રવૃત્તિ ડાયાગ્રામ જોઈ છે.
આકૃતિ 2: પ્રવૃત્તિ ડાયાગ્રામ
પ્રવૃત્તિ ડાયાગ્રામ કંટ્રોલ ફ્લો દર્શાવે છે. આકૃતિ 2 માં સચિત્ર, તમે ગોળાકાર લંબચોરસ તરીકે રજૂ પ્રવૃત્તિઓ જોઈ શકો છો. પ્રવૃત્તિઓ સામાન્ય રીતે ક્રિયા સ્ટેટ્સ € “”રાજ્યો આગામી રાજ્ય માટે સંક્રમણ આપોઆપ ક્રિયા પછી પૂર્ણ થયું છે કે છે. વર્તુળમાં ભરવામાં પ્રવૃત્તિ ડાયાગ્રામ શરૂઆત રજૂ કરે છે € “”જ્યાં નિયંત્રણ શરૂ થાય પ્રવાહ. તીર તરીકે બતાવવામાં અનુવાદ તમને બતાવવા કેવી રીતે પ્રવૃત્તિ પ્રવૃત્તિ ખસેડવા. સુમેળ બાર બતાવવા કેવી રીતે પ્રવૃત્તિઓ સમાંતર થાય છે. હું એક સંક્રમણ કહે છે કે રક્ષા કરી શકે છે, “”હું તમને આ પ્રવૃત્તિ તો જ આ પરિસ્થિતિ સાચું હોય જવા માંગો છો,”” અને જ્યાં તે બંધ હું તમને બતાવી શકે છે. હવે જો તમે ચોક્કસ વય છો, તો તમે કદાચ આ પ્રવૃત્તિ રેખાકૃતિ જુઓ અને લાગે છે, પડશે “”હમ્મ € |. કે ફ્લો ચાર્ટ જેવી લાગે છે”” અને તે બરાબર શું છે તે છે, સિવાય કે હું તે પ્રોગ્રામિંગ સ્તરે નીચે કરી રહ્યો છું. ખાસ કરીને, હું મારા વિશ્લેષણ અને ડિઝાઇન પ્રક્રિયા એકદમ પ્રારંભિક પર પ્રવૃત્તિ ડાયાગ્રામ વાપરો બિઝનેસ વર્કફ્લો દર્શાવે છે. હું પણ તેમને વાપરવા બતાવવા માટે જ્યાં મારા ઉપયોગ કિસ્સાઓમાં દરેક એક પ્રવૃત્તિ હોઈ શકે છે શું ઉપયોગ કેસ થાય છે સમજાવે પડશે. હું પણ પ્રવૃત્તિ ડાયાગ્રામ વાપરો કેવી રીતે વસ્તુઓ મારા ઉપયોગ કિસ્સાઓમાં વચ્ચે પ્રવાહ દર્શાવે છે.
પરંતુ UML વિશે મહાન વસ્તુઓ એક તેના વૈવિધ્યતાને છે. તેથી જ્યારે હું જીવનચક્ર શરૂઆતમાં પ્રવૃત્તિ ડાયાગ્રામ વાપરો, અન્ય સંપૂર્ણપણે અલગ તબક્કામાં તેમને ઉપયોગ કરી શકો છો. હું જોઇ છે લોકો પ્રવૃત્તિ ડિઝાઇન સ્તર જ્યાં તેઓ ચોક્કસ વર્ગ માટે ગાણિતીક નિયમો એક ખૂબ જ જટિલ સમૂહ હતી નીચે આકૃતિઓ ઉપયોગ કરે છે. અને ઘણા લોકો તેમને વાપરવા માટે વર્ગ પદ્ધતિઓ વચ્ચે પ્રવાહ દર્શાવે છે.
સિસ્ટમ. એક્ટર્સ લાકડી આધાર તરીકે રજૂ કરવામાં આવે છે.
આકૃતિ 4: એક્ટર્સ
ઉદાહરણ કે હું UML આ પરિચય માટે કામ કર્યું કોર્સ નોંધણી સિસ્ટમ ની થોડી મોડેલ છે. આ કિસ્સામાં તેથી, પ્રથમ વસ્તુ હું જ્યારે શરૂ મારા વિશ્લેષણ પ્રક્રિયા પૂછો, છે શું કરશે “”કોણ આ સિસ્ટમ સાથે વાતચીત કરવા જઈ રહ્યું છે?””
અલબત્ત નોંધણી મોડેલ માટે, હું એક રજિસ્ટ્રાર, પ્રોફેસર, અને એક વિદ્યાર્થી છે. હું પણ એક બાહ્ય બિલિંગ સિસ્ટમ છે. આ બિલિંગ સિસ્ટમ પણ એક અભિનેતા તરીકે લાયક ઠરે છે. (જુઓ, એક અભિનેતા એક વ્યક્તિ છે કે જે સિસ્ટમ સાથે સંપર્ક કરે છે પરંતુ સિસ્ટમ બહાર છે € “”તે કંઈપણ હોઈ નથી.)
એક ઉપયોગ કેસ સંવાદ સિસ્ટમ એક અભિનેતા દ્વારા કરવામાં સંબંધિત વ્યવહારો એક ક્રમ છે. અથવા, ઇંગલિશ માં મૂકી, એક ઉપયોગ કેસ વિધેય એક ભાગ છે. અને અહીં કી છે: તે સોફ્ટવેર મોડ્યુલ નથી € “”તે કંઈક કે જે અભિનેતા માટે કિંમત પૂરી પાડે છે.
ઉપયોગ કિસ્સાઓમાં ovals તરીકે બતાવવામાં આવે છે, અને સરળ રીતે તેમને શોધવા માટે તમારા અભિનેતા દરેક જોવા અને તમારી જાતને પૂછી જુઓ શા માટે તેઓ સિસ્ટમ ઉપયોગ કરવા માંગો છો છે. મારા કિસ્સામાં, મારા રજિસ્ટ્રાર, અભ્યાસક્રમ જાળવી રહ્યું છે મારા પ્રોફેસર એક રોસ્ટર વિનંતી કરવા જઈ રહ્યા છે, મારા વિદ્યાર્થી શેડ્યૂલ જાળવી રાખે છે, અને મારા બિલિંગ સિસ્ટમ બિલિંગ માહિતી મેળવે છે. તેથી હું દૃશ્ય ગ્રાહક બિંદુ પરથી તેને જોઈ અને, પૂછીને મારા ઉપયોગ કિસ્સાઓમાં બનાવો “”તેથી, શેઠ સિસ્ટમ અભિનેતા, શા માટે તમે સિસ્ટમ સાથે વાપરવા માંગો છો? શું કિંમત આ સિસ્ટમ માટે છે?””
આગામી પગલું, એક વાર તમે ઓળખી કાઢ્યો કેવી રીતે તમારા અભિનેતાઓ સિસ્ટમ સાથે સંપર્કમાં આવવાની આવશે, તમારા ઉપયોગ કિસ્સાઓમાં દસ્તાવેજ કરે છે. દરેક ઉપયોગ કેસ ઘટનાઓ પ્રવાહ સાથે દસ્તાવેજીકરણ કરવાની જરૂર છે, અને આ દૃશ્ય અભિનેતા બિંદુ પરથી કરવામાં આવે છે. તે વિગતવાર સિસ્ટમ ઉપયોગ જ્યારે કેસ ચલાવવામાં આવે છે અભિનેતા માટે પૂરું પાડવું જ જોઈએ જોઈએ. ખાસ કરીને તે કેવી રીતે વાપરવા કેસ શરૂ થાય છે અને સમાપ્ત જેવી વસ્તુઓ બતાવશે. શું વસ્તુઓ છે કે જે ઉપયોગ કેસ શું નથી? તમે ઘટનાઓ સામાન્ય પ્રવાહ (હું “”હેપી દિવસો”” દૃશ્ય કૉલ શું), જ્યાં બધું કામ કરે છે પડશે. પછી તમે ઘટનાઓ અસામાન્ય પ્રવાહ, “”વરસાદી દિવસ”” દૃશ્ય મળશે. જ્યારે સિસ્ટમ કામ કરતું નથી તો શું થાય? હું ઘટનાઓ કે હું હંમેશા ખુશ ટ્રેડીંગ દૃશ્ય સાથે શરૂ મારા પ્રવાહ દસ્તાવેજીકરણ દ્વારા મળી છે.
ઉદાહરણ તરીકે લો, ઓટોમેટેડ ટેલર મશીન એટીએમ સુધી વૉકિંગ. તમે એટીએમ સુધી જવામાં અને તમારા કાર્ડ દાખલ કરો. તે તમારા પિન નંબર માટે પૂછે છે. તમે તેને દાખલ કરો, અને તમને પૂછવામાં આવે કે તમે શું કરવા માંગો છો. તમે કહી “”હું કેટલાક પૈસા માંગો છો.”” તે જ્યાં નાણાં લેવામાં આવશે જોઇએ પૂછે છે. તમે તમારા ચકાસણી એકાઉન્ટમાં તેને લેવા તે જણાવો. તે કેટલી પૂછે છે. તમે $ 100.00 કહે છે. પછી જાદુ થાય છે € | તમે $ 100.00 આપે છે. પછી તે પૂછે છે જો તમે અન્ય વ્યવહાર કરવા માંગો છો. તમે કોઈ કહે છે. તે તમને તમારી કાર્ડ પાછા આપે છે, તમે એક રસીદ આપે છે, અને વ્યવહાર પર છે. તે ખુશ દિવસ દૃશ્ય છે.
બીજું દૃશ્ય. તમે એટીએમ સુધી જાય છે, તમારા કાર્ડ સામેલ કરવા માટે, અને તમારો PIN દાખલ કરો. એટીએમ તમને કહે છે તે ખોટો PIN છે. તમે તમારા નંબર ફરી દાખલ કરો. ફરીથી તમે કહ્યું છે કે પિન ખોટો છે. તમે મારા કોર્સ નોંધણી ઉદાહરણમાં, દાખલા તરીકે, તમે “”જો X પછી વાય”” વર્કફ્લો ઘણો છે કે ત્યાં જોઈ શકો છો. કે જ્યાં તમે બહાર મદદ કરવા માટે તમારા ગ્રાહક માંગો છો. મેળવવી કરાર શરૂઆતમાં તમારા ગ્રાહક આ દૃશ્યો સમજે છે અને કહે છે એનો અર્થ એ થાય “”હા, આ છે અમે શું કરવા માંગો છો.”” કારણ કે તેઓ અભિનેતાઓ, ઉપયોગ કિસ્સાઓમાં, અને તેમની વચ્ચે સંબંધો બતાવવા ઉપયોગ કિસ્સાઓમાં એક મહાન માર્ગ છે તેની ખાતરી કરવા માટે કે જે તમે શું મકાન કરી રહ્યાં છો શું ગ્રાહક માંગે છે.
આ આંકડો 5: કિસ્સામાં રેખાકૃતિ વાપરો
તેથી અમે એક મહાન ડાયાગ્રામ ગ્રાફિકલી મને શું બતાવે છે? જવાબ સરળ છે € “”તે એક મહાન રેખાકૃતિ છે કે જે સિસ્ટમ સારી ઝાંખી બતાવે છે. તે બતાવે છે કે શું સિસ્ટમ (અભિનેતા) અને કાર્યક્ષમતા સિસ્ટમ (ઉપયોગ કિસ્સાઓમાં) પૂરું પાડવું જ જોઈએ બહાર છે. જો ત્યાં એક વારસો સિસ્ટમ તમે ધ્યાનમાં લેવાની જરૂર છે, અહીં છે જ્યાં તમે તેની સાથે વ્યવહાર છે. મને મજબૂર ઇન્ટરફેસો આ પ્રકારના સાથે કામ કરવા માટે ખૂબ પ્રોજેક્ટમાં પ્રારંભિક અર્થ એ થાય કે હું કેવી રીતે હું કે કાળા બોક્સ કે હું બદલી શકતા નથી વાત કરવા જઈ રહ્યો છું બહાર આકૃતિ શરૂ થાય કોડિંગ સુધી રાહ ભાવિ સાથે સામનો કરવો પડ્યો હતો આવશે નહીં .
વધુ એક વસ્તુ તમે ઉપયોગ કિસ્સાઓમાં વિશે જાણવું જોઈએ ઉપયોગ કેસ અનુભૂતિ છે. આ “”કેવી રીતે”” ઉપયોગની કેસ છે. ક્રમ આકૃતિઓ, સહયોગ આકૃતિઓ, અને એક વર્ગ ડાયાગ્રામ અમે ભાગ વર્ગો જુઓ કોલ: તે સામાન્ય રીતે એક ડોલ કે આકૃતિઓ ત્રણ અલગ અલગ પ્રકારની સમાવે છે. ઉપયોગ કેસ મૂર્તસ્વરૂપ મૂળભૂત મળીને ઉપયોગ કિસ્સામાં ડિઝાઇન લગતી વસ્તુઓનો નંબર જૂથ એક રીત છે.
સિક્વન્સ ડાયગ્રામ્સ
સિક્વન્સ આકૃતિઓ એક સમય ક્રમ ગોઠવાય પદાર્થ ક્રિયાપ્રતિક્રિયાઓ દર્શાવે છે. હું શું વસ્તુઓ અને પ્રતિક્રિયા હું ઘટનાઓ પ્રવાહ દ્વારા સ્પષ્ટ વિધેય પરિપૂર્ણ કરવા માટે જરૂર પડશે તે નક્કી કરવા માટે ઘટનાઓ પ્રવાહ ઉપયોગ કરી શકો છો.
આકૃતિ 6: સિક્વન્સ ડાયાગ્રામને
આકૃતિ 6 બતાવે છે કે કેવી રીતે એક વિદ્યાર્થી સફળતાપૂર્વક કોર્સ ઉમેરવામાં નહીં. વિદ્યાર્થી કેટલીક માહિતી ભરે છે અને ફોર્મ જમા (માતાનો તેને જૉ કૉલ દો). ફોર્મ પછી મેનેજર વાત કરે છે અને કહે છે કે “”મઠ 101 જૉ ઉમેરો”” મેનેજર મઠ 101 તે એક વિદ્યાર્થી ઉમેરવા માટે છે કે કહે છે. મઠ 101 વિભાગ 1 કહે છે “”તમે ખોલવા?”” આ કિસ્સામાં, વિભાગ 1 જવાબો છે કે તેઓ ખુલ્લા છે, તેથી મઠ 101 આ વિદ્યાર્થી ઉમેરવા માટે વિભાગ 1 કહે છે. ફરીથી, ક્રમ આકૃતિઓ કારણ કે તેઓ તમને અને તમારા ગ્રાહક પગલું દ્વારા પગલું શું થાય છે તે બતાવવા શરૂઆતમાં મહાન સાધનો છે.
જુઓ એક વિશ્લેષણ બિંદુ પ્રતિ, હું વર્ષો મળ્યા છે કે ક્રમ આકૃતિઓ મને જરૂરિયાતો વાહન મદદ ખૂબ જ શક્તિશાળી છે; શોધવા માટે હાર્ડ હોય છે, ખાસ કરીને જરૂરીયાતો. વપરાશકર્તા ઈન્ટરફેસ જરૂરિયાતો, દાખલા તરીકે, કારણ કે તમે હંમેશા જરૂરિયાતો છે કે જે માત્ર testable નથી વિચાર જણાય છે કુખ્યાત છે. આ જેમ એક સામાન્ય UI જરૂરિયાત “”આ સિસ્ટમ વપરાશકર્તા મૈત્રીપૂર્ણ રહેશે.”” છે તમે કેવી રીતે ઘણા મૈત્રીપૂર્ણ કમ્પ્યુટર મળ્યા છે? આકૃતિઓ આ પ્રકારના લાભો છે કે એક અભિનેતા છે કે જે વ્યક્તિ રજૂ આવતા દરેક વાક્ય, તમે તમારા UI માં ક્ષમતા છે કે જે વ્યક્તિ દ્વારા જરૂરી પૂરી પાડે છે છે કે જે કંઈક કહે છે. અન્ય શબ્દોમાં, તમે testable વપરાશકર્તા ઈન્ટરફેસ જરૂરિયાતો બહાર વાહન ક્રમ આકૃતિઓ ઉપયોગ કરી શકો છો.
સિક્વન્સ આકૃતિઓ, છે તેથી, જે દર્શાવે છે શું થઈ રહ્યું છે જરૂરિયાતો ડ્રાઇવિંગ માટે, અને ગ્રાહકો સાથે કામ માટે સારી. તે સામાન્ય રીતે, પ્રશ્ન તરફ દોરી જાય છે, તેમ છતાં, કેટલા તમે બનાવવા માટે જરૂર નથી? મારો જવાબ છે, “”જ્યાં સુધી તમે પૂરતી નથી.”” તમે શોધવા જ્યારે તમે ક્રમ આકૃતિઓ છે કે તમે એક બિંદુ સુધી પહોંચવા જ્યાં તમે કોઈપણ નવા પદાર્થો શોધવામાં કરી રહ્યાં છો, કોઈપણ નવા સંદેશાઓ શોધવા નથી જઈ રહ્યાં છો, અને તમે ઉપર અને ઉપર જ વસ્તુ ટાઇપ કરી રહ્યા છે. જૉ મઠ 101 જોડાયા ઉદાહરણમાં, અમે જાણવા કે પ્રક્રિયા જ હશે તો જૉ ઇતિહાસ 101. તેથી, અંગૂઠો શાસન જોડાવા માગતા હતા દરેક ઉપયોગ કેસ દરેક મૂળભૂત પ્રવાહ માટે ક્રમ રેખાકૃતિ નથી. ઉચ્ચ સ્તર, જોખમી દૃશ્યો માટે ક્રમ રેખાકૃતિ, અને તે પર્યાપ્ત પ્રયત્ન કરીશું. કે કેટલા ક્રમ આકૃતિઓ હું શું છે.
અહીં યાદ છે, કે જે સહયોગ રેખાકૃતિ માત્ર એક દૃશ્ય એક અલગ મત છે અને તમે જુઓ શ્રેષ્ઠ તમારા બિંદુ સમજાવે છે કે વિચાર ક્રમ આકૃતિઓ અને સહયોગ આકૃતિઓ વચ્ચે આગળ અને પાછળ જઈ શકે છે.
પ્રસંગોપાત, તમે વાક્ય “”ક્રિયાપ્રતિક્રિયા આકૃતિઓ.”” સાંભળી શકે ક્યારેક લોકો સામૂહિક રીતે સહયોગ રેખાકૃતિ અને ક્રિયાપ્રતિક્રિયા રેખાકૃતિ તરીકે ક્રમ રેખાકૃતિ નો સંદર્ભ લો કરશે.
ક્લાસ ડાયાગ્રામ
એક વર્ગ સામાન્ય માળખું, સામાન્ય વર્તન, સામાન્ય સંબંધો, અને સામાન્ય ભાષાશાસ્ત્ર સાથે પદાર્થો એક સંગ્રહ છે. તમે તેમને ક્રમ અને સહયોગ આકૃતિઓ પદાર્થો પરિક્ષણ દ્વારા શોધવા માટે, અને તેઓ ત્રણ ખંડ સાથે એક લંબચોરસ તરીકે UML માં રજૂ થાય છે.
આકૃતિ 8: વર્ગો
પ્રથમ ડબ્બો, વર્ગ નામ બતાવે છે બીજા તેના માળખું (લક્ષણો) બતાવે છે, અને ત્રીજા તેની વર્તણૂક (ઓપરેશન્સ) બતાવે છે. આ ખંડ દબાવી શકાય છે, જો કે, કે જેથી તમે માત્ર નામ, માત્ર નામ અને એટ્રીબ્યૂટ્સ અથવા બધા ત્રણ જોઈ શકો છો. એક વાત તમે પણ ખબર હોવી જોઇએ કે તે મહત્વનું છે, જ્યારે વર્ગો નામકરણ, ડોમેન શબ્દભંડોળ ઉપયોગ કરે છે અને પ્રમાણભૂત બનાવ્યો છે. આ દાખલા તરીકે, મારા વર્ગો બધા એકવચન સંજ્ઞાઓ કે મૂડી પત્ર સાથે શરૂ થાય છે. તમે તેને અલગ કરવા માટે પસંદ કરી શકો છો, અને તે તો કોઈ વાંધો નથી. શું ફરક પડે છે કે જે તમારા પ્રોજેક્ટ પહેલાં તમે પ્રમાણભૂત પસંદ કરો અને તેની સાથે વળગી જેથી બધું પ્રોજેક્ટ સમગ્ર સુસંગત છે.
ક્લાસ ડાયાગ્રામ તમને તમારી સિસ્ટમનો સ્થિર પ્રકૃતિ દર્શાવે છે. આ આકૃતિઓ વર્ગો અને સિસ્ટમ લોજિકલ દૃશ્ય તેમના સંબંધો અસ્તિત્વ દર્શાવે છે. તમે એક મોડેલ ઘણી ક્લાસ ડાયાગ્રામ હશે.
UML મોડેલિંગ તત્વો ક્લાસ ડાયાગ્રામ મળી સમાવેશ થાય છે:
વર્ગો અને તેમના માળખું અને વર્તન.
એસોસિયેશન, એકંદર, પરાધીનતા, અને વારસો સંબંધો.
બાહુલ્ય અને સંશોધક સૂચકાંકો
ભૂમિકા નામો.
આકૃતિ 9. પર એક નજર આ રેખાકૃતિ બતાવે કામગીરી (વર્તન): શું છે કે વર્ગ એક પદાર્થ કરી શકો છો. હું મારા ક્રિયાપ્રતિક્રિયાઓ આકૃતિઓ જોઈને મારા કામગીરી શોધો.
આકૃતિ 9: ઓપરેશન્સ
અહીં હું કહી રહ્યો છું કે હું મઠ માટે એક વિદ્યાર્થી ઉમેરવા માટે નોંધણી મેનેજર પૂછો સમક્ષ રજુ કરવાનો પ્રયત્ન કરવાની જરૂર છે
101. એક ઓપરેશન કહેવાય ભાષાંતર કરવા માટે રહ્યું છે કે “”addCourse.””
એક વર્ગ માળખું તેના લક્ષણો દ્વારા રજૂ થાય છે. તેથી હું મારા લક્ષણો કેવી શોધી શકું? ડોમેન નિષ્ણાતના વાત કરીને. મારી જરૂરિયાતો તરફ જોઈને. મારા ઉદાહરણમાં, હું જાણવા કે દરેક કોર્સ ઓફર એક નંબર, એક સ્થાન, અને સમય હોય છે. આ ત્રણ લક્ષણો બહાર અનુવાદ.
વર્ગો. (હીરા વર્ગ સમગ્ર રજૂ આગામી સાથે સંબધિત વર્ગો જોડાઈ એક રેખા તરીકે UML માં રજૂ કરે છે.)
€ ¢ નિર્ભરતા € એક “”એક નબળા ફોર્મ ક્લાઈન્ટ અને સપ્લાયર ક્લાયન્ટ સપ્લાયર સિમેન્ટીક જ્ઞાન નથી વચ્ચે સંબંધ દર્શાવે છે. નિર્ભરતા કહે છે “”હું તમારી સેવાઓ જરૂર છે, પરંતુ મને ખબર નથી કે તમે અસ્તિત્વ ધરાવે છે.”” (ત્રુટક રેખા સપ્લાયર ક્લાઈન્ટ માંથી પોઇન્ટ તરીકે UML માં રજૂ કરે છે.)
સંબંધો શોધવા માટે, ફરી એક વાર, હું મારા ક્રમ રેખાકૃતિ પર જાઓ. બે વસ્તુઓ “”વાત”” કરવાની જરૂર છે, તો હોવી જ જોઈએ એક સાધન આવું કરવા માટે (એટલે કે, તેમના વર્ગો વચ્ચે સંબંધ).
હું ખાસ કરીને બહાર શરૂ કરો અને બધું એક કોલમ છે. હું વધુ વિશ્લેષણ કરી રહ્યો છું, હું શોધી શકે છે કે હું એક એકંદર છે, કારણ કે હું એક પિતૃ બાળક સંબંધ કાળજી લેવા માટે હોય જાઉં છું. જ્યારે હું ડિઝાઇન તબક્કા માં વિચાર, હું શોધવા કે હું એક કોલમ કારણ કે કોઈ બીજા € મારા પદ્ધતિઓ “”તેથી હું તેને નિર્ભરતા બનાવવા એક માં કે પદાર્થ પસાર થઈ રહ્યું છે જરૂર પડી શકે છે.
આકૃતિ 11: સંબંધો
આકૃતિ 11 તમે આ સંબંધો જુઓ. એસોસિયેશન કહે છે પ્રોફેસર કોર્સ ઓફર, અને કોર્સ ઓફર કરવા માટે વાત કરી શકો છો પ્રોફેસર સાથે વાત કરી શકો છો. સંદેશાઓ શરૂ કરી શકાય છે અને માહિતી કોઈપણ દિશામાં પ્રવાહ શકો છો. એકંદર આ કિસ્સામાં એક કોર્સ અંજલી અપ કરવામાં આવે છે સમગ્ર € તરફ ડાયમંડ “”હોવાના બતાવવામાં આવે છે. આ એકંદર માટે કારણ મારા વિકાસકર્તાઓ કહેવું છે કે જો તેઓ આ કોર્સ છૂટકારો મેળવવા માટે, તેઓ કદાચ કંઈક કોર્સ ઓફર સાથે ખાસ કરવું પડશે હશે. આધારિત ત્રુટક રેખા તરીકે બતાવવામાં આવે છે. તે કહે છે કે નોંધણી મેનેજર સૂચિ અલ્ગોરિધમ પર આધાર રાખે છે કંઈક કરવું. સૂચિ અલ્ગોરિધમ ક્યાં પદ્ધતિઓ એક પરિમાણ છે અથવા નોંધણી વ્યવસ્થાપક પદ્ધતિઓ એક સ્થાનિક જાહેર કરવામાં આવે છે.
બાહુલ્ય અને નેવિગેશન
બાહુલ્ય વ્યાખ્યાયિત કેટલા વસ્તુઓ સંબંધ ભાગ લે છે. તે અન્ય વર્ગ એક ઉદાહરણ સંબંધિત એક વર્ગ ઉદાહરણો સંખ્યા છે. સંબંધ દરેક ઓવરને માટે એક: દરેક એસોસિયેશન અને એકંદર માટે, ત્યાં બનાવવા માટે બે અનેકતા નિર્ણયો છે. બાહુલ્ય નંબર તરીકે રજૂ થયેલ છે અને * ઘણા બાહુલ્ય પ્રતિનિધિત્વ કરવા માટે વપરાય છે.
આકૃતિ 12: બાહુલ્ય અને સંશોધક
એક પ્રોફેસર ઓબ્જેક્ટ શૂન્ય-થી-ચાર કોર્સ ઓફર ઓબ્જેક્ટો સાથે સંબંધિત છે. ઓબ્જેક્ટ ઓફર એક કોર્સ બરાબર એક પ્રોફેસર ઓબ્જેક્ટ સાથે સંબંધિત છે. હું આ ઉપયોગ જોવા અને ખાતરી કરો કે આ મારી જરૂરિયાતો સંભાળે છે. હું કોર્સ ઓફર કરી શકાય છે અને પ્રોફેસરો એક ટોળું દ્વારા કરવામાં ટીમના શીખવવામાં? ના, કારણ કે આ હું માત્ર એક પ્રોફેસર છે શકે છે. હું એક પ્રોફેસર હોઈ શકે છે અને રજા પર હોઈ શકે છે? હા, કારણ કે આ કહે છે હું શક્ય કોર્સ લોડ તરીકે શૂન્ય છે. હું ઘણી વાર અનેકતા ઉપયોગ કરવા માટે મદદ માટે મને કબજે અને મારા બિઝનેસ નિયમો અમલમાં શરૂ કરો. જો તમારી પાસે છે, ઉદાહરણ તરીકે, એક બિઝનેસ નિયમ કહે છે કે તમે ઓછામાં ઓછા 3 વિદ્યાર્થીઓ અને કોર્સ માટે આ બોલ પર કોઈ વધુ 10 કરતાં એક સત્ર માં ઓફર હોય છે જ જોઈએ, આ અનેકતા નંબરો મને કહો હું આ યોજના માં બિઝનેસ નિયમ સામેલ છે.
નેવિગેશન એક તીર દ્વારા બતાવવામાં આવે છે, અને તેમ છતાં એસોસિએશનો અને એગ્રિગેશન બંને બાજુથી મૂળભૂત રીતે છે, તે ઘણી વાર એક જ દિશામાં ભ્રમણ પ્રતિબંધિત ઇચ્છનીય છે. જ્યારે સંશોધક રોકેલ છે, એક એરોહેડ નેવિગેશનલ દિશા દર્શાવે છે ઉમેરવામાં આવે છે. વસ્તુઓ વિશ્લેષણ અને ડિઝાઇન તબક્કાઓ દરમિયાન હું શું એક હું શું યુનિ-દિશા પ્રયત્ન કરવા માંગો છો જુઓ. આ રેખાકૃતિ માં તીર મૂકીને, હું કહું છું કે જે રજીસ્ટ્રેશન વ્યવસ્થાપક કોર્સ એક સંદેશ મોકલી શકો છો, કારણ કે તે જાણે છે કોર્સ અસ્તિત્વમાં છે. પરંતુ કોર્સ કોઈ વિચાર છે કે જે રજીસ્ટ્રેશન વ્યવસ્થાપક અસ્તિત્વમાં છે, તેથી કોર્સ એક સંદેશ શરૂ કરી શકો છો. હવે માહિતી તેમની વચ્ચે પ્રવાહ કરી શકો છો; જો તે ઓપન છે દાખલા તરીકે નોંધણી વ્યવસ્થાપક કોર્સ પૂછી શકો છો અને કોર્સ કહી શકો છો તે છે. પરંતુ માત્ર નોંધણી વ્યવસ્થાપક કે વાતચીત શરૂ કરી શકો છો.
દેખીતી રીતે અહીં ધ્યેય તરીકે તમે સમય દ્વારા તમે ડિઝાઇન સમાપ્ત થાય છે કારણ કે તે વારસો જાળવી રાખવા માટે ખૂબ સરળ સિસ્ટમ ત્રિકોણ સાથે બતાવવામાં આવે છે કારણ કે ઘણા તીર વિચાર છે. આ બતાવે છે પ્રોફેસર નોંધણી વપરાશકર્તા છે કે, વિદ્યાર્થી છે. હવે, ચેતવણી એક શબ્દ. વારસો ઉપયોગી છે, જો કે, ધ્યેય તરીકે ખૂબ વારસામાં તમારી સિસ્ટમ માટે પરવાનગી આપે છે વાપરવા માટે નથી. હું કેટલાક ખરેખર ક્રૂર સિસ્ટમો જ્યાં તેઓ વારસો 17 સ્તર ઊંડા હતી જોઇ છે. જો તેઓ એક વસ્તુ બદલી હોય, તે એક આપત્તિ બની હતી. તેથી મુખ્ય નિયમ વારસો વાપરવા માટે માત્ર જ્યારે તમે ખરેખર એક વારસો પરિસ્થિતિ હોય છે.
રાજ્ય સંક્રમણ આકૃતિઓથી
એક રાજ્ય સંક્રમણ રેખાકૃતિ આપેલ વર્ગ જીવન ઇતિહાસ બતાવે છે. તે ઘટનાઓ કે જે એક રાજ્યમાં બીજા સંક્રમણ કારણ, અને ક્રિયાઓ કે જે રાજ્ય ફેરફાર માંથી પરિણમી બતાવે છે.
આકૃતિ 14: રાજ્ય સંક્રમણ રેખાકૃતિ
હું પદાર્થ વર્ગો કે જે ખાસ કરીને ગતિશીલ વર્તન ઘણો હોય છે માટે રાજ્ય સંક્રમણ આકૃતિઓથી ઉપયોગ કરે છે. બટન € પર છે | બટન બંધ છે; હું તે માટે એક રાજ્ય ચાર્ટ કરવા માટે નથી જતા છું. પરંતુ પદાર્થ વર્ગો ગતિશીલ વર્તન ઘણો હોય છે, હું કદાચ વસ્તુઓ સ્ટેટ્સ માં જોવા માટે હોય છે જાઉં છું.
હું રાજ્ય એક ગોળાકાર ત્રિકોણ છે, જે દર્શાવે દ્વારા શરૂ કરો. હું શરૂઆતમાં સ્ટેટ્સ હોઈ શકે છે, અને હું બંધ સ્ટેટ્સ, જે બળદો આંખો તરીકે બતાવવામાં આવે છે હોઈ શકે છે. હું પણ સ્ટેટ્સ, અથવા રક્ષક સંક્રમણો (વસ્તુઓ છે કે જે થાય છે જ્યારે ત્યારે જ એક શરત સાચી છે), અથવા વસ્તુઓ થાય છે કે જ્યારે હું રાજ્ય અંદર છું વચ્ચે રૂપાંતરણ કરી શકે છે. હું આ રેખાકૃતિ જુઓ અને કોર્સ ઓફર રાજ્ય સંક્રમણ રેખાકૃતિ જુઓ. તે આરંભ સ્થિતિમાં શરૂ થાય છે, અને ત્યાં સુધી હું એક “”વિદ્યાર્થી ઉમેરો”” સંદેશ વિચાર હું કે જે રાજ્યમાં રહે છે. જ્યારે હું કે સંદેશ વિચાર, હું શૂન્ય વિદ્યાર્થી મારા ગણક સેટ અને હું ખુલ્લા રાજ્ય માટે સંક્રમણ. તમે આકૃતિ 14 કે હું એક એન્ટ્રી છે જુઓ, અને પડશે કારણ શા માટે તે ત્યાં છે કે હું રાજ્ય માં મેળવવાની બે માર્ગો છે. તે કહે છે કે કોઈ બાબત તમે કેવી રીતે રાજ્ય આવે, હું તમને વિદ્યાર્થી રજીસ્ટર કરવા માંગો છો. જ્યારે હું કે રાજ્ય બહાર નીકળવા, ગણક ફેરફારો દરમિયાન વિદ્યાર્થીઓની સંખ્યા ટ્રેક રાખવા માટે. હું ત્યાં સુધી હું 10 મેળવવા વિદ્યાર્થીઓ ઉમેરી શકો છો, અને પછી હું બંધ રાજ્ય પર જાઓ. એક વાર અભ્યાસક્રમ નક્કી, હું રોકવા રાજ્ય માટે સંક્રમણ. જ્યાં કોઈ બાબત હું પછી છું, જો હું રદ ઇવેન્ટ સંક્રમણ વિચાર, હું મારા વિદ્યાર્થીઓ જાણ અને પછી બંધ રાજ્ય માટે સંક્રમણ.
પદાર્થ વર્ગો ગતિશીલ વર્તન ઘણો હોય છે કે, તે બધું થાય છે કે પર નિયંત્રણ મેળવવા માટે રાજ્ય રેખાકૃતિ કરવા માટે તે સારી રીતે વર્થ છે. તમારી જાતને પૂછો શું થાય છે જ્યારે હું એક સંદેશ વિચાર? જ્યારે હું મેસેજ મળે છે હું શું કરી શકું? હું શું સંદેશાઓ મોકલવા માટે હોય છે? તે સંદેશાઓ ઘણાં આ ઉદાહરણ છે જ્યાં ઉમેરો વિદ્યાર્થી કામગીરી છે કારણ કે, પદાર્થ વર્ગ કામગીરી બની જાય છે. આ ક્રિયાઓ ઘણો, ગણક સુયોજિત ગણક incrementing, ગણક ચકાસણી જેમ, આ બધા છે કે જે ચોક્કસ પદાર્થ વર્ગ ખાનગી કામગીરી બને છે અને એક રાજ્ય રેખાકૃતિ છે જ્યાં હું જોઈ.
જો તમે એક ગતિશીલ પદાર્થ વર્ગ હોય તો તમે કેવી રીતે ખબર નથી? ફરી એક વાર, ક્રમ આકૃતિઓ પર પાછા જાઓ. તમે એક પદાર્થ વર્ગ ક્રમ આકૃતિઓ ઘણો પર છે કે હોય છે અને તે મેળવવામાં અને સંદેશા ઘણો મોકલવા છે, તો તે એક સારો સંકેત તે એકદમ ગતિશીલ પદાર્થ વર્ગ છે અને તે કદાચ તે માટે એક રાજ્ય ચાર્ટ હોવો જોઈએ. પણ એગ્રિગેશન છે, જ્યાં તમે તેના ભાગો સમગ્ર છે માટે, હું દરેક એકંદર સમગ્ર માટે રાજ્ય ચાર્ટ નથી. હું મોટે ભાગે આવું કારણ કે એકંદર સમગ્ર વારંવાર મેસેજિંગ છે, જે તેને ગતિશીલ બનાવે છે વ્યવસ્થા કરવા માટે જવાબદાર છે.
પુન આકૃતિઓ
અલબત્ત કોઈ સિસ્ટમ ધ્યાનમાં ભૌતિક વિશ્વ લીધા વગર બાંધવામાં કરી શકાય છે. કે જ્યાં ઘટક આકૃતિઓ આવે છે. તેઓ સોફ્ટવેર ઘટકો વચ્ચે સંસ્થાઓ અને આધારભૂતપણાઓ સમજાવવા માટે, સ્ત્રોત કોડ ઘટકો, સમય ઘટકો ચલાવો, અથવા એક એક્ઝેક્યુટેબલ ઘટક સહિત વપરાય છે. આકૃતિ 15 માં જોવા મળે કોમ્પોનન્ટ્સ, બાજુ પર બે નાના લંબચોરસ સાથે એક મોટી લંબચોરસ તરીકે શો છે.
આકૃતિ 15: ઘટકો
તે રાઉન્ડ વસ્તુઓ ઇન્ટરફેસો (ઘણી વખત કહેવાય લોલીપોપ સંકેત) પ્રતિનિધિત્વ કરે છે. આ કિસ્સામાં, તેઓ દર્શાવે છે કે Register.exe બંને Course.dll અને People.dll માટે ઇન્ટરફેસો પર આધાર રાખે છે. એનો અર્થ એ થાય કે જો આ ઇન્ટરફેસો બદલવા માટે, તેને Register.exe અસર કરશે. મને ખબર છે કે આ નિયમ છે જ્યારે તમે ઇન્ટરફેસો નિર્માણ કરી રહ્યાં છો કે જે કહે છે કે “”તું ઈન્ટરફેસ બદલવા નહિ.”” પરંતુ કોઈની ખરેખર કામ કરે છે, જ્યાં કે નિયમ લાગુ કરવામાં આવે છે? આ રેખાકૃતિ અમને કહે છે શું ઇન્ટરફેસો ઉપયોગ કરવામાં આવે છે શું દ્વારા પ્રોગ્રામ મારા પ્રોસેસરો પર ચાલી રહ્યું છે.
આકૃતિ 16: જમાવટ રેખાકૃતિ
UML વિસ્તરે
છેલ્લા વસ્તુ હું UML વિશે ભાર માંગો છો કે વિસ્તૃત કરી શકાય છે. જ્યારે તેઓ UML બાંધવામાં, તેઓ ખૂબ જ કુશળતાઓનો ઉપયોગ કરીને કુશળતાપૂર્વક ભાન કોઈ રીતે તેઓ એક સંકેત છે કે જે લોકો તમામ કૃપા કરીને શકે સમયના તમામ બનાવી શકે છે ત્યાં હતો. જેથી તેઓ અમને એક બીબાઢાળ ખ્યાલ આપ્યો હતો. બીબાઢાળ હું મૂળભૂત મોડેલિંગ તત્વ ભરે છે અને તેને વધુ અર્થ આપી શકે છે કહે છે. પરંપરાગત રીતો વર્ગીકરણ અને સંગઠનો, વારસો સંબંધો, વર્ગો, અને ઘટકો વિસ્તારવા માટે ઉપયોગ કરી શકે છે.
આકૃતિ 17: વેબ બીબાઢાળ ઉદાહરણ
17 આંકડો અમારા વેબ પ્રથાઓ રેખાકૃતિ બતાવે છે. વેબ પેજ સામાન્ય રીતે સામગ્રી કે જે સર્વર અને સામગ્રી કે જે ક્લાઈન્ટ પર ચાલે રન કર્યા છે. તમે વેબ આધારિત કાર્યક્રમો નિર્માણ કરી રહ્યાં છો, તો શું ક્લાઈન્ટ પર ચાલી રહ્યું છે અને સર્વર મહત્વપૂર્ણ મહત્વ છે. તેથી અમે પ્રથાઓ કે દર્શાવે છે કે એક સંપૂર્ણ સેટ છે. લિટલ વ્હીલ વસ્તુઓ સર્વર પર ચાલે છે કે પ્રતિનિધિત્વ કરે છે. તેથી માત્ર આ એક રેખાકૃતિ હું જોઈ શકો છો સર્વર પર શું ચાલે છે જોઈને, શું ક્લાઈન્ટ પર ચાલે છે, અને શું બિઝનેસ વસ્તુઓ તેઓ સાથે વ્યવહાર હોય છે.

“——————————————————————————————————————————————————

tradiksyon sipò: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”UML a se lang nan estanda pou espesifye, vizualizan, konstwi, ak dokimante tout zafè yo nan yon sistèm lojisyèl.””
aktivite Dyagram
Kote ki lojik yo kòmanse mache nan kèk nan dyagram ki UML se pa gade nan aktivite dyagram.
Figi 2: dyagram aktivite
dyagram aktivite montre koule nan kontwòl. Kòm montre nan Figi 2, ou ka wè aktivite reprezante kòm awondi rektang. Aktivite yo, se tipikman eta aksyon â € “”eta yo ki tranzisyon otomatikman nan eta a pwochen apre aksyon an se konplè. reprezante a plen nan sèk kòmansman an nan dyagram nan aktivite â € “”kote koule nan kontwòl kòmanse. Transitions montre kòm flèch montre ki jan ou deplase soti nan aktivite nan aktivite. ba senkronizasyon montre ki jan aktivite rive nan paralèl. Mwen kapab veye yon tranzisyon ki di “”Mwen vle ou pou yo ale nan aktivite sa a sèlman si kondisyon sa a se vre,”” e mwen ka montre w ki kote li sispann. Koulye a, si ou se yon laj sèten, ou pral pwobableman gade nan sa a dyagram aktivite ak panse, “”hmm â € |. Ki sanble ak yon tablo koule”” Epi sa a, egzakteman sa li ye, eksepte Mwen pa fè li desann nan nivo a pwogram. Tipikman, mwen sèvi ak yon dyagram aktivite san patipri byen bonè nan nan analiz ak konsepsyon pwosesis mwen an montre workflow biznis. Mwen pral tou itilize yo montre kote chak nan ka itilize mwen ta ka nan yon aktivite ilistre sa ka itilize te rive. Mwen menm mwen te sèvi ak aktivite dyagram yo montre ki jan bagay sa yo koule ant ka itilize m ‘yo.
Men, yonn nan bagay ki gwo sou UML a se adaptabilite li yo. Se konsa, pandan mwen sèvi ak aktivite dyagram nan kòmansman an nan lifecycle a, lòt moun ka sèvi ak yo nan yon faz diferan nèt. Mwen te wè moun ki sèvi ak aktivite dyagram desann nan nivo nan konsepsyon kote yo te gen yon seri bagay ki konplike anpil nan algoritm pou yon klas an patikilye. Anpil moun lòt nasyon sèvi ak yo yo montre koule ki genyen ant metòd yo nan yon klas.
sistèm nan. Aktè yo reprezante kòm figi bwa.
Figi 4: Aktè
Egzanp lan ke mwen te travay moute pou entwodiksyon sa a UML se yon modèl ti kras nan yon sistèm anrejistreman kou. Se konsa, nan ka sa a, premye bagay la mwen ta fè lè kòmanse pwosesis analiz mwen an se mande, “”ki moun ki pral kominike avèk sistèm sa a?””
Pou modèl la enskripsyon kou, mwen gen yon rejistrè, yon pwofesè, ak yon elèv yo. Mwen gen tou yon sistèm bòdwo ekstèn. sistèm bòdwo sa a tou kalifye kòm yon aktè. (Gade, yon aktè pa gen yo dwe yon yon moun € “”li nan nenpòt ki bagay ki reyaji ak sistèm nan men se deyò nan sistèm nan.)
Yon ka itilize se yon sekans nan tranzaksyon ki gen rapò fèt pa yon aktè nan sistèm lan nan yon dyalòg. Oswa, yo mete l ‘nan lang angle, yon ka itilize se yon ti moso nan fonctionnalités. Ak isit la nan kle a: li se pa yon lojisyèl modil â € “”li se yon bagay ki bay valè nan aktè a.
Sèvi ak ka yo montre kòm oval, ak fason ki pi fasil jwenn yo se fè yon gade nan chak nan aktè ou a epi mande tèt ou poukisa yo vle sèvi ak sistèm la. Nan ka m ‘yo, rejistrè mwen ki pral yo kenbe kourikoulòm nan, pwofesè mwen ki pral pou mande pou yon lis, elèv mwen kenbe orè a, ak sistèm voye bòdwo mwen resevwa enfòmasyon ki voye bòdwo. Se konsa, mwen kreye ka itilize mwen pa gade li soti nan pwen an kliyan de vi epi mande, “”se konsa, sistèm msye aktè, poukisa ou vle sèvi ak sistèm la? Ki sa ki valè sistèm sa a bay ou?””
Pwochen etap la, yon fwa ou te idantifye ki jan aktè ou yo pral kominike avèk sistèm nan, se dokimante ka sèvi ak ou. Chak ka itilize bezwen yo dwe dokimante ak koule nan evenman yo, ak sa a se fè soti nan pwen aktè a nan de vi. Li ta detay ki sa sistèm nan dwe bay aktè a lè se ka a itilize egzekite. Tipikman li pral montre bagay sa yo tankou ki jan ka a itilize kòmanse ak Otermin. Ki bagay ki itilize ka dwe fè? Ou ap gen koule nan nòmal nan evènman (sa mwen rele “”jou kè kontan”” senaryo a), kote tout bagay ap travay. Lè sa a, ou pral jwenn koule nan nòmal nan evènman yo, “”jou lapli”” senaryo a. Kisa k ap pase lè sistèm la pa travay? Mwen te jwenn pa dokimante koule m ‘lan nan evènman ki mwen toujou kòmanse ak senaryo a kontan jou.
Pran kòm yon egzanp, mache moute nan yon machin Teller otomatik. Ou mache jiska ATM lan ak insert kat ou. Li mande pou nimewo PIN ou yo. Ou antre nan li, epi ou yo mande ki sa ou ta renmen fè. Ou di “”Mwen vle kèk lajan.”” Li mande kote yo ta dwe lajan an dwe te pran nan men. Ou di l ‘bay pran li nan men kont chèk ou. Li mande konbyen lajan. Ou di $ 100.00. Lè sa a, majik k ap pase â € | li ba ou $ 100.00. Lè sa a, li mande si ou vle yon lòt tranzaksyon. Ou di pa gen okenn. Li ba ou kat ou tounen, ba ou yon resi, ak tranzaksyon an se sou. Sa a senaryo a jou kè kontan.
Dezyèm senaryo. Nou mèt al nan ATM lan, insert kat ou, ak antre nan PIN ou. ATM nan di ou li nan PIN a mal. Ou antre nan nimewo ou ankò. Yon fwa ankò w ap di yo ke PIN la se kòrèk. Ou Nan enskripsyon mwen egzanp kou, pou egzanp, ou ka wè ke gen yon anpil nan “”si X Lè sa a, Y”” workflows. Sa a kote ou vle kliyan ou a ede ou deyò. Lè w akò byen bonè vle di kliyan ou konprann senaryo sa yo e li di “”wi, sa a se ki sa nou vle.”” Sèvi ak ka se yon bon fason asire ke sa ou ap bati se reyèlman sa kliyan an vle, paske yo montre aktè yo, ka yo itilize, ak relasyon ki genyen ant yo.
Figi 5: Sèvi ak dyagram ka
Se konsa, nou gen yon gwo dyagram ki grafikman montre m ‘ki sa? Repons lan se senp â € “”li se yon dyagram gwo ki montre yon BECA bon nan sistèm lan. Li montre ki sa ki ki andeyò sistèm nan (aktè) ak fonctionnalités a ke sistèm la dwe bay (itilize ka). Si gen yon sistèm eritaj ou bezwen pran an konsiderasyon, isit la nan kote ou fas ak li. Fòse m ‘yo travay avèk sa yo kalite interfaces byen bonè nan pwojè a vle di ke mwen pa pral fè fas ak Prospect nan ap tann jiskaske kodaj kòmanse eseye figi konnen kouman mwen pral pale ak sa yo ki bwat nwa ke mwen pa ka chanje .
Yon lòt bagay ou ta dwe konnen sou ka itilize se realizasyon an itilize ka. Sa a se “”ki jan”” yo itilize a ka-a. Li nan anjeneral yon bokit ki gen twa diferan kalite dyagram: dyagram sekans, dyagram kolaborasyon, ak yon dyagram klas ke nou rele yon gade nan klas k ap patisipe. Sèvi ak ralizasyon ka yo fondamantalman yon fason pou gwoupman ansanm yon nimewo nan zafè ki gen rapò ak desen an nan yon ka sèvi ak yo.
sekans Dyagram
dyagram Sekans montre entèraksyon objè ranje nan yon sekans tan. Mwen ka itilize koule nan evènman detèmine kisa ki objè ak entè-aksyon mwen ap bezwen akonpli fonksyonalite a espesifye nan koule nan nan evènman yo.
Figi 6: dyagram Sekans
Figi 6 montre kouman yon elèv avèk siksè vin ajoute nan yon kou. Elèv la (kite a rele l ‘Joe) plen nan kèk enfòmasyon yo epi soumèt fòm nan. Fòm nan Lè sa a, pale ak manadjè a ak di “”ajoute Joe yo Matematik 101.”” Manadjè a di Matematik 101 ke li gen yo ajoute yon elèv. Matematik 101 di Seksyon 1 “”yo se ou louvri?”” Nan ka sa a, Seksyon 1 replies yo ke yo yo louvri, se konsa Matematik 101 di seksyon 1 yo ajoute elèv sa a. Yon fwa ankò, dyagram sekans yo se zouti gwo depi nan konmansman an paske yo montre w ak kliyan ou etap-pa-etap sa ki te rive.
Soti nan yon pwen analiz de vi, mwen te jwenn sou ane yo ki dyagram sekans yo trè pwisan nan ede m ‘kondwi kondisyon; espesyalman kondisyon ki difisil jwenn. Itilizatè koòdone kondisyon, pou egzanp, yo repite paske ou toujou sanble yo jwenn kondisyon ki yo se jis pa teste. Yon kondisyon UI komen tankou sa a se “”sistèm sa a va user-zanmitay.”” Konbyen nan ou gen te rankontre yon òdinatè zanmitay? Youn nan benefis ki genyen nan sa yo kalite dyagram se ke chak liy vini soti nan yon aktè ki reprezante yon moun, di ou ke yon bagay nan UI ou a gen yo bay yon kapasite bezwen pou moun sa a. Nan lòt mo, ou ka itilize dyagram sekans nan kondwi soti teste kondisyon koòdone itilizatè.
dyagram Sekans yo, Se poutèt sa, bon pou ki montre sa k ap pase sou li a, pou kondwi soti kondisyon, ak pou travay ak kliyan yo. Sa anjeneral mennen nan kesyon an, menm si, nan konbyen ou bezwen yo kreye? Repons mwen se, “”jiskaske ou fè ase.”” W ap ale nan chèche konnen lè ou fè dyagram sekans ke ou rive nan yon pwen kote ou pa ap jwenn nenpòt objè nouvo, pa jwenn nenpòt ki mesaj nouvo, e ke w ap tape menm bagay la sou yo ak sou. Nan egzanp lan nan Joe rantre nan Matematik 101, nou aprann ke pwosesis la ta dwe menm bagay la tou si Joe te vle rantre nan Istwa 101. Se konsa, règ nan gwo pous, fè yon dyagram sekans pou chak koule debaz yo nan chak itilize ka. Fè yon dyagram sekans pou wo-nivo, senaryo ki riske, e ke yo ta dwe ase. Sa a ki jan anpil dyagram sekans m ‘fè.
sonje isit la, se ke yon dyagram kolaborasyon se jis yon View diferan nan yon senaryo epi ou ka ale retounen ak lide ant dyagram sekans ak dyagram kolaborasyon yo ka resevwa gade nan ki pi byen montre pwen ou yo.
Okazyonèlman, ou ta ka tande fraz “”dyagram ki entèraksyon.”” Pafwa moun ap kolektivman, al gade nan yon dyagram kolaborasyon ak yon dyagram sekans kòm yon dyagram entèraksyon.
Gwoup Dyagram
Yon klas se yon koleksyon objè ki gen estrikti komen, konpòtman komen, relasyon komen, ak Semantics komen. Ou jwenn yo lè nou ekzamine objè yo nan sekans ak kolaborasyon dyagram, epi yo ap reprezante nan UML a kòm yon rektang ki gen twa konpatiman.
Figi 8: Klas
lòj nan premye montre non nan klas, dezyèm nan montre estrikti li yo (atribi), ak twazyèm lan montre konpòtman li yo (operasyon). konpatiman sa yo ka siprime, sepandan, pou ke ou ka wè jis non an, jis non an ak atribi figi yo, oswa tout twa. Youn nan bagay ou ta dwe tou konnen se ke li enpòtan, lè nonmen klas, yo sèvi ak vokabilè a nan domèn nan, epi chwazi yon estanda. Pou ka sa a, klas mwen, yo tout nouen sengilye ki kòmanse ak yon lèt kapital la. Ou ka chwazi fè li yon lòt jan, e ke pa gen pwoblèm. Ki sa pwoblèm se ke anvan pwojè ou ou chwazi yon estanda ak bwa avèk li pou ke tout bagay se ki konsistan atravè pwojè a.
Gwoup Dyagram montre w nati a estatik nan sistèm ou an. dyagram sa yo montre egzistans lan nan klas ak relasyon yo nan gade nan ki lojik nan yon sistèm. Ou pral gen dyagram klas anpil moun nan yon modèl.
Eleman yo UML modèl yo te jwenn nan dyagram klas yo enkli:
Klas ak estrikti yo ak konpòtman.
Association, agrégation, depandans, konsa jaden relasyon.
Miltiplikasyon ak navigasyon endikatè
Wòl non.
Pran yon gade nan Figi 9. dyagram sa a montre operasyon (konpòtman): ki sa yon objè nan ki klas ka fè. Mwen jwenn operasyon mwen pa gade nan entèraksyon dyagram m ‘yo.
Figi 9: Operasyon
Men mwen ap di ke mwen bezwen pou kapab mande manadjè a enskripsyon yo ajoute yon elèv nan Matematik
101. Sa k ap pase yo tradwi nan yon operasyon yo rele “”addCourse.””
Se estrikti a nan yon klas reprezante pa atribi li yo. Se konsa, kouman mwen jwenn atribi mwen an? Pa pale ak ekspè domèn. Pa gade nan kondisyon m ‘yo. Nan egzanp mwen, mwen aprann ke chak ofrann kou gen yon nimewo, se yon kote, ak yon tan. Tradui sa a soti nan twa atribi.
klas yo. (Reprezante nan UML a kòm yon liy ki konekte klas yo ki gen rapò ak yon dyaman pwochen nan klas la reprezante tout la.)
â € ¢ Depandans â € “”yon fòm pi fèb ki montre relasyon ki genyen ant yon kliyan ak yon founisè kote kliyan an pa gen konesans semantik nan founisè a. Yon depandans di “”mwen bezwen sèvis ou, men mwen pa konnen ke ou egziste.”” (Reprezante nan UML a kòm yon liy an tirè montre nan men kliyan an a founisè a.)
Pou jwenn relasyon, yon fwa ankò, m ‘ale tounen nan dyagram sekans m’ yo. Si de objè bezwen “”pale””, dwe gen yon vle di fè sa (dir, yon relasyon ant klas yo).
I yo kòmanse deyò epi yo fè tout bagay yon asosyasyon. Jan nou konnen mwen ap fè plis analiz, mwen ta ka jwenn mwen gen yon agrégation paske mwen pral fè yo pran swen nan yon relasyon paran-pitit. Lè m ‘jwenn nan faz nan konsepsyon, mwen chèche konnen ke mwen pa ta ka bezwen yon asosyasyon paske yon moun lòt bagay ki pral konsa, objè nan youn nan metòd mwen â € “”Se konsa, mwen fè l’ yon depandans.
Figi 11: Relasyon
Nan Figi 11 ou wè relasyon sa yo. Kòm asosyasyon di pwofesè a ka pale ak bèt yo ofri pou kou, ak bèt yo ofri pou kou ka pale ak pwofesè a. Mesaj ka inisye ak done ka koule soti nan nenpòt direksyon. se agregasyon montre pa gen dyaman a nan direksyon tout â € nan “”nan ka sa a se yon kou te fè leve nan ofrann kou. Rezon ki fè la pou sa a agrégation ta dwe di devlopè mwen ke si yo debarase m de sa a kou, yo pral pwobableman gen fè yon bagay espesyal ak ofrann yo kou. Dependencies yo montre kòm yon liy an tirè. Li nan ki di ke manadjè a enskripsyon depann sou Algorithm a Orè fè yon bagay. Algorithm nan Orè se swa yon paramèt nan youn nan metòd yo oswa se te deklare lokalman pa youn nan metòd yo nan Manadjè a Enskripsyon.
Miltiplikasyon ak Navigasyon
Miltiplikasyon defini konbyen objè patisipe nan yon relasyon. Li se ki kantite chans pou yo yon klas ki gen rapò ak yon sèl egzanp nan klas la ak lòt. Pou chak asosyasyon ak agrégation, gen de desizyon miltiplikasyon fè: yonn pou chak fen nan relasyon an. Miltiplikasyon se reprezante kòm yon nimewo epi li se yon * itilize yo reprezante yon miltiplikasyon nan anpil moun.
Figi 12: multiplisite ak navigasyon
Yon objè Pwofesè ki gen rapò ak zewo-a-kat objè kou Ofri. Yon kou Ofri objè ki gen rapò ak egzakteman yon objè Pwofesè. Mwen sèvi ak sa a fè yon gade nan epi asire ke sa a manch kondisyon m ‘yo. Èske mwen ka gen yon Ofri kou yo epi yo dwe ekip-anseye pa yon pakèt moun sou pwofesè? Non, paske sa a di mwen kapab sèlman gen yon sèl pwofesè. Èske mwen ka gen yon pwofesè epi yo dwe sou sabatik? Wi, paske sa a di mwen gen yon zewo kòm chaj kou posib. Mwen sèvi ak miltiplikasyon byen souvan pote m ‘sekou kòmanse kaptire ak mete ann aplikasyon règleman biznis mwen an. Si ou gen, pou egzanp, yon règ biznis ki di ou dwe gen omwen 3 elèv yo ak pa plis pase 10 pou yon kou yo dwe ofri nan yon semès, nimewo miltiplikasyon sa yo di m ‘mwen te enkòpore règ sa a biznis nan plan sa a.
Navigasyon se yo montre nan yon flèch, ak byenke asosyasyon ak rasanbleman yo bi-direksyon pa default, li se souvan dezirab mete restriksyon sou navigasyon nan yon sèl direksyon. Lè Navigasyon sou restriksyon, se yon Arrowhead ajoute nan endike direksyon an navigasyon. Youn nan bagay ki mwen fè pandan analiz ak konsepsyon faz yo se gade nan sa m ‘vle yo dwe uni-direksyon. Pa mete flèch la nan dyagram sa a, mwen di ke Manadjè a Enskripsyon ka voye yon mesaj bay kou a, paske li konnen kou a egziste. Men, kou a pa gen okenn lide ki Manadjè a Enskripsyon egziste, se konsa kou a pa ka kòmanse yon mesaj. Koulye a, done ka koule ant yo; pou egzanp Manadjè a Enskripsyon ka mande kou a si li nan louvri, epi kou a ka di ke li se. Men, se sèlman Manadjè a Enskripsyon ka kòmanse ki konvèsasyon.
Li evidan objektif la isit la se yo jwenn kòm anpil flèch jan ou ka pa tan an ou te fini desine, paske li nan yon sistèm pi fasil yo kenbe Pòsyon tè yo montre ak yon triyang. Sa a montre ke Pwofesè a se yon Enskripsyon itilizatè, kòm se Elèv la. Koulye a, yon mo nan avètisman. Pòsyon tè se itil, sepandan, objektif la se pa sèvi ak pòsyon tè otan ke sistèm ou pral pèmèt. Mwen te wè kèk sistèm reyèlman brital kote yo te gen pòsyon tè 17-nivo fon anpil. Si yo chanje yon sèl bagay, li te vin yon dezas. Se konsa, règ la nan gwo pous se yo sèvi ak pòsyon tè sèlman lè ou se vre wi: fè gen yon sitiyasyon pòsyon tè.
Eta Tranzisyon Dyagram
Yon dyagram tranzisyon eta montre istwa a lavi nan yon klas bay yo. Li montre evènman yo ki lakòz yon tranzisyon soti nan yon eta a yon lòt, ak aksyon sa yo ki sòti nan yon chanjman eta a.
Figi 14: Eta dyagram tranzisyon
Mwen sèvi ak dyagram tranzisyon eta a pou klas objè ki tipikman gen yon anpil nan konpòtman dinamik. Bouton an se sou yon € | bouton a se koupe; Mwen pa pral fè yon tablo eta a pou li. Men, klas objè ki gen yon anpil nan konpòtman dinamik, mwen pwobableman pral fè yo gade nan eta yo nan objè yo.
Mwen kòmanse lè yo montre yon eta, ki se yon triyang balanse. Mwen ka gen eta kòmanse, e mwen ka gen eta sispann, ki fè yo montre kòm jenn ti towo bèf je yo. Mwen kapab yo te genyen tou tranzisyon ant eta, oswa tranzisyon gad palè (bagay sa yo ke rive lè sèlman lè yon kondisyon se vre), oswa bagay sa yo ke rive lè mwen se andedan eta a. Mwen gade nan dyagram sa a ak wè dyagram nan tranzisyon eta a pou yon ofrann kou. Li kòmanse nan eta a inisyalizasyon, epi mwen rete nan eta sa a jouk tan mwen jwenn yon “”ajoute elèv”” mesaj. Lè m ‘jwenn ki mesaj, mwen mete konte m’ lan nan elèv a zewo ak mwen tranzisyon nan eta a ki Open. Ou pral wè nan Figi 14 ke mwen gen yon antre, ak rezon an pou kisa li nan gen ke mwen gen de fason pou trape nan eta sa a. Li di ke pa gen okenn pwoblèm ki jan ou antre nan eta a, mwen vle nou enskri elèv la. Lè m ‘sòti ke eta, chanjman sa yo konte nan kenbe tras nan ki kantite elèv ki nan kou a. Mwen kapab kenbe ajoute elèv yo, jouk tan mwen ale nan 10, ak sa, mwen pral bay eta a Fèmen. Yon fwa yo kou a fini, mwen tranzisyon nan eta a ki kanpe. Pa gen pwoblèm kote m ‘prale lè sa a, si mwen jwenn Anile tranzisyon an Evènman, mwen fè elèv mwen ak Lè sa a tranzisyon nan eta a ki kanpe.
Pou klas objè ki gen yon anpil nan konpòtman dinamik, li nan byen vo li fè yon dyagram eta yo ka resevwa yon manch sou tou sa ki gen rive. Mande tèt ou sa ki pase lè mwen jwenn yon mesaj? Kisa pou mwen fè lè mwen jwenn mesaj la? Ki sa ki pou bay mesaj pou mwen te voye? Yon anpil nan sa yo mesaj vin operasyon nan klas la objè, tankou nan egzanp sa a kote ajoute yon elèv se yon operasyon. Yon anpil nan aksyon sa yo, tankou mete konte a, incrementing konte a, tcheke konte a, sa yo tout vin operasyon prive nan ki klas objè patikilye ak yon dyagram Eta a se kote mwen wè sa.
Jan ou fè konnen si ou gen yon klas objè dinamik? Yon fwa ankò, tounen nan dyagram ki sekans. Si ou gen yon klas objè sa a, se sou yon anpil nan dyagram sekans ak li a ap resevwa ak voye yon anpil nan mesaj, sa a, se yon endikasyon ki bon li nan yon klas objè san patipri dinamik epi li ta dwe pwobableman gen yon tablo eta a pou li. Epitou pou rasanbleman, kote ou gen tout la nan pati li yo, m ‘fè yon tablo eta a pou chak antye total. Mwen fè sa sitou paske ke tout total se souvan responsab pou jere messagerie la, ki fè li dinamik.
Component dyagram
Natirèlman ka pa gen okenn sistèm ap bati san yo pa pran an kont mond lan fizik. Sa a kote dyagram eleman vini nan. Yo itilize yo montre òganizasyon sa yo ak Dependencies nan mitan eleman lojisyèl, ki gen ladan eleman kòd sous, kouri eleman tan, oswa yon eleman ègzèkutabl. Eleman yo montre kòm yon rektang gwo ak de rektang ki pi piti sou bò a, jan yo wè nan Figi 15.
Figi 15: Eleman
Moun sa yo ki bagay sa yo wonn reprezante interfaces (souvan yo rele bonbon notasyon). Nan ka sa a, yo montre ke Register.exe a se depann sou interfaces nan tou de Course.dll a ak People.dll la. Sa vle di si interfaces sa yo chanje, li pral impact Register.exe la. Mwen konnen ke gen nan règ sa a lè w ap bati interfaces ki di “”ou pa dwe chanje koòdone nan.”” Men, okenn moun aktyèlman ap travay ki kote règ sa a fè respekte restriksyon? Dyagram sa a di nou sa interfaces yo te itilize pa sa ègzèkutabl se kouri sou processeurs mwen.
Figi 16: deplwaman dyagram
pwolonje UML
Bagay la pase mwen vle estrès sou UML a se ke li kapab pwolonje. Lè yo bati UML a, yo ‘pase reyalize ke te gen okenn fason yo te kapab kreye yon notasyon ki ta ka tanpri tout moun nan pèp la tout nan tan an. Se konsa, yo te ban nou konsèp nan yon stereotip. Yon stereotip di mwen ka pran yon eleman modèl debaz epi remèt li plis sans. Estereyotip kapab itilize yo klasifye ak pwolonje asosyasyon, relasyon pòsyon tè, klas, ak konpozan.
Figi 17: Web stereotip egzanp
Figi 17 montre dyagram nan nan Estereyotip wèb nou an. Yon paj entènèt tipikman gen bagay ki kouri sou sèvè a ak lòt bagay ki kouri sou kliyan an. Si w ap bati aplikasyon pou sit entènèt ki baze sou, sa k ap kouri sou kliyan an ak sèvè a se ki gen enpòtans enpòtan anpil. Se konsa, nou gen yon seri antye nan Estereyotip ki montre sa. Wou yo ti kras reprezante bagay sa yo ki kouri sou sèvè a. Se konsa, jis pa gade nan yon sèl sa a dyagram mwen kapab wè sa ki kouri sou sèvè a, ki sa kouri sou kliyan an, ak sa ki biznis objè yo gen fè fas ak.

“——————————————————————————————————————————————————

Support translation: http://amzn.to/1Z7d5oc
——————————————————————————————————————————————————
UML2notes

“”The UML ne misali harshen for tantancewa, visualizing, gina, da kuma tattara bayanai da dukan kayayyakin gargajiya da wani software tsarin.””
Activity zane-zane
The ma’ana wuri don fara tafiya, ta hanyar wasu daga cikin zane-zane UML ne ta hanyar kallon aiki zane-zane.
Figure 2: Activity zane
Activity zane-zane nuna da ya kwarara daga iko. Kamar yadda aka kwatanta a cikin Figure 2, za ka iya ganin ayyukan wakilta a matsayin taso keya rectangles. Ayyukan ne yawanci mataki jihohin â € “”ya furta cewa, gwamnatin rikon kwarya ta atomatik zuwa na gaba jihar bayan mataki ne complete. A cike a da’irar wakiltar farko na aiki zane â € “”inda ya kwarara daga iko fara. Canji nuna yadda kibiyoyi nuna yadda ka matsa daga aiki zuwa aiki. Aiki tare sanduna nuna yadda ayyukan faru a layi daya. Zan iya tsare a miƙa mulki cewa ya ce “”Ina so ka je wannan aiki ne kawai idan wannan yanayin ne gaskiya,”” kuma zan iya nuna maka inda ya tsaya a nan ba. Yanzu idan kana da wani da shekaru, za ku ji yiwuwa dubi wannan aiki zane da kuma tunani, “”Hmm â € | da kama wani kwarara ginshiƙi.”” Kuma wanda ke daidai da abin da shi ne, sai dai ina ba yin shi sauka a shirye-shirye matakin. Yawanci, na amfani da wani aiki zane fairly da wuri a cikin ta bincike da kuma zane tsari ya nuna kasuwanci aikace-aikace. Zan kuma yi amfani da su don nuna inda kowanne daga ta amfani lokuta zai yi a cikin wani aiki domin ya nuna abin da amfani da yanayin ya faru. Na kuma yi amfani da aiki zane-zane ya nuna yadda abubuwa daga ƙarƙashinsu tsakanin amfani lokuta.
Amma daya daga cikin manyan abubuwa game da UML ne da versatility. To yayin da na yi amfani da aiki zane-zane a farkon lifecycle, wasu za su iya amfani da su a cikin wani daban-daban lokaci gaba ɗaya. Na gani mutane amfani aiki zane-zane sauka a zane matakin inda suka yana da matukar rikitarwa kafa Algorithms na musamman ajin. Kuma mutane da yawa yi amfani da su don nuna kwarara tsakanin hanyoyin da wani ajin.
cikin tsarin. Actors ake wakilta a matsayin sanda Figures.
Figure 4: Actors
The misali da cewa na yi aiki up for wannan gabatarwar UML ne kadan model na shakka rajista tsarin. To, a cikin wannan misali, abu na farko da zan yi a lokacin da suka fara ta analysis tsari ne ka yi tambaya, “”wanda yake faruwa hulɗa tare da wannan tsarin?””
Ga hanya rajista model, Ina da rejista, wani farfesa, kuma dalibi. Na kuma da wani waje da lissafin kuɗi da tsarin. Wannan lissafin kuɗi da tsarin kuma cancantar a matsayin actor. (Dubi, an actor ba dole ba ne ya zama mutum â € “”yana da wani abu da interacts tare da tsarin amma a waje na da tsarin.)
A amfani yanayin ne a jerin related ma’amaloli yi da wani actor a cikin tsarin a cikin wani maganganu. Ko kuma, a saka shi a cikin harshen Turanci, a yi amfani da yanayin ne a bantara na ayyuka. Kuma a nan ne key: shi ne, ba a software module â € “”shi ne wani abu da bayar darajar da actor.
Amfani lokuta an nuna su kamar ovals, kuma mafi sauki hanyar gano su ne a duba a kowane of your ‘yan wasan kwaikwayo da kuma tambayi kanka me suke so su yi amfani da tsarin. A yanayin, ta rejista da yake faruwa kula da manhaja, ta farfesa yake faruwa nemi a zakara, ta dalibi kula da jadawalin, kuma ta cajin kudi tsarin na’am da lissafin kuɗi da bayanai. Sabõda haka na haifar da ta yi amfani da lokuta da kallon shi daga abokin ciniki nufi da ra’ayi da kuma tambayar, “”don haka, mister tsarin actor, me ya sa ka ke so ka yi amfani da tsarin? Menene darajan wannan tsarin samar da zuwa gare ku?””
The mataki na gaba, da zarar ka gano yadda ‘yan wasan kwaikwayo za a hulda tare da tsarin, shi ne do tattara bayanai da yin amfani lokuta. Kowane amfani harka bukatar a rubuce tare da ya kwarara daga abubuwan da suka faru, kuma wannan ne yake aikata daga actor ta batu na view. Ya kamata daki-daki, abin da tsarin dole ne samar da actor a lõkacin da amfani yanayin da ake kashe. Yawanci shi zai nuna abubuwa kamar yadda amfani harka fara da kare. Menene abubuwa ne cewa amfani harka suka yi? Za ku ji da al’ada kwarara daga abubuwan da suka faru (abin da na kira da “”farin ciki kwanaki”” scenario), inda duk abin da ya aikata aiki. Sa’an nan za ku ji samun mahaukaci kwarara daga abubuwan da suka faru, da “”ruwa rana”” labari. Menene ya faru sa’ad da tsarin ba ya aiki? Na same tattara bayanai ta kwarara daga abubuwan da na ko da yaushe fara da farin ciki kwanaki labari.
Take a matsayin misali, yana tafe har zuwa wani mai sarrafa kansa teller na’ura. Za ka yi tafiya har zuwa ATM kuma saka your katin. Yana tambaya for your PIN number. Ka shigar da shi, kuma an ce muku abin da kuke so a yi. Ka ce “”Ina son wasu kudi.”” Yana tambaya inda kudi ya kamata a dauka daga. Ka gaya da shi a yi da shi, daga dubawa account. Yana tambaya nawa. Ka ce $ 100,00. Sa’an nan sihiri faru â € | shi ya ba ka $ 100,00. Sa’an nan kuma ya tambaye idan kana so wani ma’amala. Za ka ce ba. Yana ba ka your katin baya, ya ba ku a samu, da kuma ma’amala ne a kan. Wannan shi ne farin ciki rana labari.
Na biyu labari. Ka haura zuwa ATM, saka your katin, da kuma shigar da PIN. The ATM gaya muku yana da PIN kuskure. Ka shigar da lambar kuma. Again an ce muku cewa PIN ba daidai ba. Zaka A hanya rajista misali, ga misali, za ka iya ganin cewa akwai mai yawa “”idan X to Y”” workflows. Shi ke inda ka ke so abokin ciniki ya taimake ka fita. Samun yarjejeniyar farkon nufin abokin ciniki fahimci wadannan al’amura kuma ya ce “”eh, wannan shi ne abin da muke so.”” Amfani lokuta ne mai girma